Re: Help Me Please :)

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <wccya74m18e.fsf@world.std.com>,
	Robert A Duff <bobduff@world.std.com> wrote:

>Mats Weber <matsw@mail.com> writes:
>
>> I think the designers of Modula-3 got it just right. You can have a look
>> at http://www.m3.org/
>
>I beg to differ, again.  ;-)
>
>I see several problems with Modula-3's exception mechanism, some of
>which are shared by Ada.  (My knowledge of the language comes from
>Harbison's book, "Modula-3".  I've never written a Modula-3 program.)

I agree with you about the Modula-3 problems.  Do not entirely agree with
you about Ada.  There could be some benefits to the paramterized 
exception, but these would be small and are already adequately covered
by the features of Ada.Exceptions.   Dr. Dewar and I do not usually
agree on the benefits of the functions in Ada.Exceptions, but we do
agree that exceptions are overused in most applications.

>There's no hierarchy of exceptions.  This means that the designer of
>some code that raises exceptions must decide on the granularity of
>exception handling; it would be better for the handler to make that
>decision.  For example, one handler might want to handle all "I/O
>errors", whereas another handler might want to handle just "disk-full
>error".  Making exceptions first-class objects (which they are not, in
>Ada and Modula-3) would solve this problem, at no cost in language
>complexity.

There would certainly be an increase in complexity in the creation
of hierarchical exceptions.  

>An exception takes just one parameter.  Why not two or three or however
>many I like?  Again, making exceptions extensible object types would
>solve the problem.

And what would be the parameter type(s)?  Are you suggesting an
exception defined with parameters in the same way one defines 
subprograms?  That would seem to increase complexity of both the
compiler design and the resulting applications.  It is an increase
in complexity that seems unnecessary under any but the most unusual
circumstances.    

>The behavior in the presense of "checked run-time errors" (things like
>divide by zero, arithmetic overflow, array index out of bounds) is not
>defined by the language.  So an array index out of bounds might raise
>Array_Index_Error on one implementation, and Constraint_Error on another
>implementation, and simply stop the program dead in its tracks on a
>third implementation.  I don't like that non-portability.

I agree it is useful to track such things.  That is why I like the
addition of Exception_Occurrence to the language in Ada.Exceptions.

      when Some_Nasty_Error : Constraint_Error =>
        Error_Manager.Log(Ada.Exceptions.
                         Exception_Information(Some_Nasty_Error));

This is where Dr. Dewar and I differ.  I see this feature as important
for applications such as command and control systems.  He sees it, as
of our last discussion of the subject, as less important than I.

>(On the other hand, Ada *pretends* that it's OK to raise and handle
>Constraint_Error, but if you read RM-11.6, you'll find that's not quite
>true -- and I doubt if any Ada programmer other than Tucker Taft
>actually *understands* 11.6.  So in practise, 11.6 says, "Do not handle
>predefined exceptions.")

ALRM 11.6 rarely presents a problem to the applications programmer. It
behaves according to a set of rules that has no deleterious effect on
the underlying application.  It is, as I read it, as set of permissions,
not a license to destroy source code intent.

>The "raises set" of a procedure defines what exceptions it can raise.
>The problem is that this rule is checked at run time.  Java is closer to
>the right solution -- it checks that rule at compile time.  However,
>Java suffers from the "cry wolf" problem.  I think it's possible to
>avoid the "cry wolf" problem, and still do most of that checking at
>compile time.

The entire C-family of languages, especially C++, is somewhat problematic
when examining exception handling.  This is another of the "devil is in 
the details" issues.  I don't think Java exception handling measures
up in those circumstances that Ada does well.  Ada is simpler to 
understand and probably a little more efficient.  Also, Java exception
handling seems to lead people to depend too much on exception handling
when they ought to be writing programs to check conditions instead. Ada
95 has added the 'Valid attribute for such checking and it can be used
nicely in circumstances where one might otherwise raise an exception.

I am reminded of C.A.R. Hoare's Turing Award Lecture in which he criticized
Ada for having exception as part of the language.  Now every language
has some kind of exception handling.  Ada looks downright conservative
when compared to more recent offerings for exception management.

>There is no re-raise statement (spelled "raise;" in Ada), so a "when
>others" handler (Ada spelling again) can't propagate the same exception.
>You can't raise the same exception occurrence, because the thing
>available in the handler is not the occurrence, but just its parameter,
>and then only if you named a particular exception.

A Reraise_Occurrence is included in Ada.Exceptions.  It is not very
difficult to invoke this routine when one declares a limited type of
Exception_Occurrence and attaches it to some Exception_ID.  In fact,
one may save an Exception_Occurrence and raise it again at some other
point in the program.  


>Return and exit statements are defined in terms of raising a RETURN or
>EXIT exception.  That seems kludgy to me, because exceptions are for
>cases where the target of the jump is determined dynamically, whereas
>return and exit are jumping to a statically-known place.  So it's sort
>of overkill.  In practical terms, it means that a "when others" will
>handle a RETURN or EXIT, and you can't re-raise it, so the return
>doesn't actually return, and the exit doesn't actually exit the loop.

As mentioned above, it is possible to save and Exception_Occurrence
and ReRaise it.  As to return types, it is also useful to use a 'Base
value for certain return types and check those on return.  Of course,
you know this feature better than I.  You also understand the 
excellent arguments against doing it this way.

>All exceptions must be declared at top level.  This solves the
>kludginess of Ada, where they can be declared anywhere, but act *as if*
>they were declared at top level.  But I think there are better solutions
>to that problem, based on the "procedure declares what exceptions it can
>raise" idea of Modula-3, Java, etc.

Agree that exceptions should be declared at a very high ("top") level.
This is done quite nicely using child library units where the top level
of a hierarchy is the declaration of the exceptions one will use
throughout that hierarchy.  In this case, they are also in scope for 
any clients.   

>There's nothing like Eiffel's preconditions, postconditions, and
>invariants, which tie exceptions to the conditions that cause them.  In
>Modula-3, you can say "this thing might raise Stack_Full", whereas in
>Eiffel you can say, "this thing will raise Stack_Full if Full(S) is
>True."

No argument with your ideas about Eiffel.  I would like to have some
model for pre-, post-, and invariants in the next version of Ada.  At
that time, it would be appropriate to revisit some of the capabilities
of exception handling.  

That being said, as you know, most safety-critical software will avoid
exceptions entirely.  Another reason why the new 'Valid attribute is
becoming useful.  

>So, I think CLOS, Clu, and Eiffel (and to some small extent, C++) all
>have better ideas about exceptions than Modula-3 (or Ada).

Agree about Eiffel.  Not sure about CLOS or Clu.  Definitely disagree
about C++.  The exception handling in C++ can only be described as scary.

Richard Riehle