Improving Ada Exceptions

Improving Ada Exceptions

[Ray Blaak]

Hello all. I am an Ada fanatic who has just started his first C++ project.
Being thoroughly ingrained against the evils of C++ I was quite surprised to
find it not as bad as I expected. There are many horrible aspects about it, to
be sure, but one thing I find very cool is C++'s exception mechanism.

It is a very powerful thing to be able to throw and catch arbitrary objects,
since one can cleanly place whatever appropriate information is relevant to the
error. By catching objects of a base class, one can handle whole classes of
errors at once.

The Ada 83 exception method is clean and simple but suffers from the inability
to pass data with the exception. Ada 95 adds the ability to pass strings with
the exception, but in an inelegant way, in my opinion. One now has the
Ada.Exceptions library package, exception ids, exception occurrences, and
mutiple ways to raise on exception (i.e. the raise keyword and
Ada.Exceptions.Raise_Exception). Part of the complexity comes from the fact
that Ada exceptions are just names, not data objects, but the result seems a
kind of hack. Surely there can be a conceptually simpler way.

So how About extending the semantics of raise to simply allow arbitrary objects
to be raised, as in C++? To handle an arbitrary thrown object, the "when"
branches of an exception handle could look like a good-old-fashioned variable
declaration (there is already a precedent syntactically with "when e : others
=>""). Consider this simple example:

type Out_Of_Range is record
  Hi : Integer;
  Low : Integer;
  Value : Integer;
end record;
...
if (...Some Failure...)
  raise Out_Of_Range'(Hi => 0, Low => 99, Value => Input_Value);
end if;
...
exception
  when Error : Out_Of_Range =>
    Text_Io.Put_Line ("out of range. " & Integer'Image(Error.Value) &
                      " not in" & Integer'Image(Error.Low) & " .." &
                      Integer'Image(Error.Hi));
end;

Consider a heirarchy of exception types:

package Math_Exception is
  type Math_Error is tagged record with private;
  function Message_Of (Error : in Math_Error) return String;

  type Integer_Divide_By_Zero_Error is new Math_Error with private;
  -- Message_Of is inherited.
  function Bad_Denominator_Of (Error : in Integer_Divide_By_Zero_Error)
    return Integer;

  -- other error types...
private
  -- whatever...
end Math_Exception;

Now fielding a heirarchy of errors:

begin
  -- some bogus calculation    
exception
  when Error : Math_Exception.Integer_Divide_By_Zero_Error =>
    Text_Io.Put_Line 
      ("divide by zero with " 
       & Integer'Image(Math_Exception.Bad_Denominator_Of(Error)));
  when Error : Math_Exception.Math_Exception'Class =>
    -- handle any other math errors
    Text_Io.Put_Line (Math_Exception.Message_Of(Error));
end;

It seems to me that this proposal fits fairly cleanly and orthogonally with the
existing language design. Of course, I could be missing something fundamental.
I would like to see a discussion on the merits and disadvantages of this
approach. Some things I am interested in:

01. Implementation complexity: Is this hard to do? Given that this is already
    implemented in C++, and GNAT especially can take advantage of gcc's
    implementation, is there something specific to Ada that would make it more
    difficult? What about throwing controlled types?
02. Safety issues: Will this violate anything? Throwing objects containing
    pointers to static objects comes to mind. 
03. Conceptual coolness: I think that this approach makes use of existing
    syntax pretty simply and cleanly. It also, I think, does not preturb the
    existing exception mechanism. What are some problems? One might be that
    "raise" is typeless. One either has to raise a variable, or a type
    qualified literal or aggregate.
04. Anything else?

--  
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Improving Ada Exceptions

[Chris Morgan]

I think the use of exception objects in C++ is yet another piece of
overly complex c++ garbage. Although all kinds of wild and wonderful
schemes can be proposed with their use, in fact most sensible
exception handling strategies don't need any more facilities than Ada
offers (in fact Ada83 exceptions seem good enough), in my experience
(your mileage may vary). Leaving theoretical discussion aside I am
talking about when you have a particular program or library and
consider what possible action you can take in the presence of an
exception. When you get specific enough there never seems to be a good
reason to mess with the basics.

On the other hand I wouldn't mind being proved wrong. Why not modify
GNAT on something like Linux and show what is possible in a real
system that was not possible before. Or find someone who knows how to
hack GNAT and get them to have a go.

Chris
-- 
 	"everything remotely enjoyable turns out to be 
 	 powerfully addictive and expensive and bad for you"
						- Lizzy Bryant

Re: Improving Ada Exceptions

[Tucker Taft]

For what it is worth, we proposed during the Ada 9X revision 
allowing more flexibility in the exception mechanism, allowing for a 
hierarchy of exceptions, treating exception declarations approximately
like type declarations, and treating "raise" statements
approximately like creating an instance of the exception type.

At the time, it was felt to be overkill.  I suspect there might
be more sympathy for it today, though if you look at how exceptions
are used, many of them are used to represent unanticipated errors rather 
than anticipated messages to be received by higher level code.  

Java has an interesting approach, where some classes of exceptions
are presumed to be unanticipated errors (and no local handler or "throws"
clause is required), whereas others are required to have local handlers, or
a "throws" clause that announces that the exception might be propagated.
Unlike in C++, these rules are enforced at compile-time, which
seems much more useful.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Improving Ada Exceptions

[Alan E & Carmel J Brain]

Chris Morgan wrote:
> 
> I think the use of exception objects in C++ is yet another piece of
> overly complex c++ garbage. Although all kinds of wild and wonderful
> schemes can be proposed with their use, in fact most sensible
> exception handling strategies don't need any more facilities than Ada
> offers (in fact Ada83 exceptions seem good enough), in my experience
> (your mileage may vary).

The only practical problems I've seen with Ada-83 exceptions is handling
them when you have arrays of tasks. The exception handler cannot know a
priori which of the tasks raised the exception, and so needs attention.
Yes, the task itself could handle the exception by setting a flag in a
boolean array of the same size, saying "look at me", but that's a bit of
a kludge!
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Improving Ada Exceptions

[Larry Kilgallen]

In article <873elnu41d.fsf@mihalis.i-have-a-misconfigured-system-so-shoot-me>, Chris Morgan <mihalis@ix.netcom.com> writes:
> I think the use of exception objects in C++ is yet another piece of
> overly complex c++ garbage. Although all kinds of wild and wonderful
> schemes can be proposed with their use, in fact most sensible
> exception handling strategies don't need any more facilities than Ada
> offers (in fact Ada83 exceptions seem good enough), in my experience
> (your mileage may vary).

My experience is that Ada83 exception mechanisms are not sufficient
to readily log the exceptional experience for transmission back to
those who can analyze it.  With Ada83 I have found it necessary to
resort to platform-specific non-Ada hacks to achieve this.

On paper, Ada95 seems to address all these issues, but it is not
available on VAX VMS and will never be available on really old
versions of VAX VMS (nor will C++, of course).

Larry Kilgallen

Re: Improving Ada Exceptions

[Tom Moran]

>I don't think exceptions are "implemented in C++" yet. gnu g++ does not
  I understand MS Windows CE supports Windows exceptions, but not C++
exceptions.

Re: Improving Ada Exceptions

[James S. Rogers]

The biggest problem I have seen with C++ style exceptions is that they can
throw and catch any class.  You must know several things about a C++
exception before you can properly handle it.  First you must know the class
of the exception.  You cannot simply catch an exception, then determine its
class.  You must catch each class explicitly.  This means that using C++
exceptions on a large project can be very difficult.  Each function must
know
the explicit classes of all exceptions it may need to catch.  The result,
in my
experience, is that a development team decides which class to use for all
exceptions.  The most generally useful exception class is a string class.

The result is that practical use of C++ exceptions only uses a subset of
the
possiblities.  That subset is completely subsumed by the package
Ada.Exceptions.  The result is that Ada contains all that is really useful
about
exceptions, even in C++, without the confusion which can result from 
uncontrolled use of classes.  I would no like to see Ada adopt the C++
exception model.  It would be a step away from usefulness towards the
appearance of flexibility.

Jim Rogers
Colorado Springs, Colorado

Ray Blaak <blaak@infomatch.com> wrote in article
<63072n$q6r$1@berlin.infomatch.com>...
> Hello all. I am an Ada fanatic who has just started his first C++
project.
> Being thoroughly ingrained against the evils of C++ I was quite surprised
to
> find it not as bad as I expected. There are many horrible aspects about
it, to
> be sure, but one thing I find very cool is C++'s exception mechanism.
> 
> It is a very powerful thing to be able to throw and catch arbitrary
objects,
> since one can cleanly place whatever appropriate information is relevant
to the
> error. 

Re: Improving Ada Exceptions

[Stephen Leake]

Ray Blaak wrote:
> 
> <proposal for Ada exceptions more like C++>
 
> 01. Implementation complexity: Is this hard to do? Given that this is already
>     implemented in C++, and GNAT especially can take advantage of gcc's
>     implementation, is there something specific to Ada that would make it more
>     difficult? What about throwing controlled types?

I don't think exceptions are "implemented in C++" yet. gnu g++ does not
support them. In Borland C++ 5.02 for Windows 95, if you throw an
exception from a constructor, the stack (or something) is corrupted, and
you eventually crash the machine. My impression is that other
implementations also have problems with C++ exceptions (I have not used
any other implementations).

Does anyone use a C++ implementation that actually supports all the
semantics of the draft C++ standard exceptions?

> --
> Cheers,                                        The Rhythm is around me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,
> blaak@infomatch.com                            The Rhythm has my soul.

-- 
- Stephe

Re: Improving Ada Exceptions

[Balmacara9]

>Subject: Improving Ada Exceptions
>From: blaak@infomatch.com (Ray Blaak)
>Date: Sun, Oct 26, 1997 14:52 EST
>Message-id: <63072n$q6r$1@berlin.infomatch.com>
>
>Hello all. I am an Ada fanatic who has just started his first C++ project.
>Being thoroughly ingrained against the evils of C++ I was quite surprised to
>find it not as bad as I expected. There are many horrible aspects about it,
>to
>be sure, but one thing I find very cool is C++'s exception mechanism.
>
>It is a very powerful thing to be able to throw and catch arbitrary objects,
>since one can cleanly place whatever appropriate information is relevant to
>the
>error. By catching objects of a base class, one can handle whole classes of
>errors at once.
>
>The Ada 83 exception method is clean and simple but suffers from the
>inability
>to pass data with the exception. Ada 95 adds the ability to pass strings with
>the exception, but in an inelegant way, in my opinion. One now has the
>Ada.Exceptions library package, exception ids, exception occurrences, and
>mutiple ways to raise on exception (i.e. the raise keyword and
>Ada.Exceptions.Raise_Exception). Part of the complexity comes from the fact
>that Ada exceptions are just names, not data objects, but the result seems a
>kind of hack. Surely there can be a conceptually simpler way.
>
>So how About extending the semantics of raise to simply allow arbitrary
>objects
>to be raised, as in C++? To handle an arbitrary thrown object, the "when"
>branches of an exception handle could look like a good-old-fashioned variable
>declaration (there is already a precedent syntactically with "when e : others
>=>""). Consider this simple example:
>
>type Out_Of_Range is record
>  Hi : Integer;
>  Low : Integer;
>  Value : Integer;
>end record;
>...
>if (...Some Failure...)
>  raise Out_Of_Range'(Hi => 0, Low => 99, Value => Input_Value);
>end if;
>...
>exception
>  when Error : Out_Of_Range =>
>    Text_Io.Put_Line ("out of range. " & Integer'Image(Error.Value) &
>                      " not in" & Integer'Image(Error.Low) & " .." &
>                      Integer'Image(Error.Hi));
>end;
>
>Consider a heirarchy of exception types:
>
>package Math_Exception is
>  type Math_Error is tagged record with private;
>  function Message_Of (Error : in Math_Error) return String;
>
>  type Integer_Divide_By_Zero_Error is new Math_Error with private;
>  -- Message_Of is inherited.
>  function Bad_Denominator_Of (Error : in Integer_Divide_By_Zero_Error)
>    return Integer;
>
>  -- other error types...
>private
>  -- whatever...
>end Math_Exception;
>
>Now fielding a heirarchy of errors:
>
>begin
>  -- some bogus calculation    
>exception
>  when Error : Math_Exception.Integer_Divide_By_Zero_Error =>
>    Text_Io.Put_Line 
>      ("divide by zero with " 
>       & Integer'Image(Math_Exception.Bad_Denominator_Of(Error)));
>  when Error : Math_Exception.Math_Exception'Class =>
>    -- handle any other math errors
>    Text_Io.Put_Line (Math_Exception.Message_Of(Error));
>end;
>
>It seems to me that this proposal fits fairly cleanly and orthogonally with
>the
>existing language design. Of course, I could be missing something
>fundamental.
>I would like to see a discussion on the merits and disadvantages of this
>approach. Some things I am interested in:
>
>01. Implementation complexity: Is this hard to do? Given that this is already
>    implemented in C++, and GNAT especially can take advantage of gcc's
>    implementation, is there something specific to Ada that would make it
>more
>    difficult? What about throwing controlled types?
>02. Safety issues: Will this violate anything? Throwing objects containing
>    pointers to static objects comes to mind. 
>03. Conceptual coolness: I think that this approach makes use of existing
>    syntax pretty simply and cleanly. It also, I think, does not preturb the
>    existing exception mechanism. What are some problems? One might be that
>    "raise" is typeless. One either has to raise a variable, or a type
>    qualified literal or aggregate.
>04. Anything else?
>
>--  
>Cheers,                                        The Rhythm is around me,
>                                               The Rhythm has control.
>Ray Blaak                                      The Rhythm is inside me,
>blaak@infomatch.com                            The Rhythm has my soul.
>
>
>
>
>
>
>
>

Passing an object is nice, but I hate the try/catch mechanism which is also
 present in Java. The Ada exception handler blows away the C++/Java constructs.

Re: Improving Ada Exceptions

[Marc Wachowitz]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote:
> throwing an exception object out of the scope of its class would be a
> possibility that would have to be blocked some way.

One way which would catch this problem in an (IMO) acceptable way,
concerning both performace and language complexity, would be to require
that the types of (potential) exception objects be subtypes of some
particular type (say, Ada.Exceptions.Dynamic_Object), and then enclose a
nested scope declaring such subtypes within an implicit handler for
all such types declared immediately at its level, which then raises a
particular exception (say, Ada.Exceptions.Out_Of_Scope) with appropriate
information to find out the full name of the type of the original
exception (this information would be intended for logging/debugging,
similar to what you can get now). Any overhead for the implicit handler
would only appear if a nested potential exception type is declared and
the compiler cannot figure out that no such exception would otherwise
escape its proper scope. (Note that in most environments, it's even
possible to implement exceptions with zero time overhead as long as they
are not raised, and the additional overhead for these implicit handlers
if an innocent exception is raised would hardly be worth worrying about.)

A somewhat different problem (which doesn't arise with CLOS, Java or C++)
is that exception categories via subtyping tend to make most sense if you
can put exceptions into several independent categories (i.e. multiple
supertyping). While multiple views can be implemented reasonably well in
Ada (and I even tend to prefer its tool-box approach to usual multiple
inheritance in most situations), this particular problem seems to demand
a more dynamic selection based on all available views, rather than only
access through some known view. I'm not sure how this would best fit into
the subtyping model of Ada-95 as we know it, and I'd fear that a naive
attempt to use a single-inheritance hierarchy as exception categorization
would easily lead to long-term trouble.

Of course, if all you need is to get some more information about the
exception through to the handler (e.g. which i/o-error happend with
which file, what was the error code from the system call), it would be
sufficient to associate an arbitrary object (with the above safety net)
with an exception, but still select exception handlers only based on an
explicitly named exception - similar to the way Modula-3 does it (which
does have garbage collection, and doesn't need such a safety net for
data, though it's still limited for nested procedures, which cannot be
assigned to any variable at all, but only passed as procedure argument).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

Re: Improving Ada Exceptions

[Richard A. O'Keefe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]


blaak@infomatch.com (Ray Blaak) writes:

>Hello all. I am an Ada fanatic who has just started his first C++ project.
>Being thoroughly ingrained against the evils of C++ I was quite surprised to
>find it not as bad as I expected. There are many horrible aspects about it, to
>be sure, but one thing I find very cool is C++'s exception mechanism.

Does anyone know whether C++ copied the idea of throwing an object
from CLOS?  The 'condition system' in Common Lisp goes back a long way.
Maybe the idea of throwing objects is just obvious.

Of course, there _is_ the wee problem of running a constructor so you
can throw a 'storage exhausted' exception, but a few prebuilt exceptions
will fix that.

>It is a very powerful thing to be able to throw and catch arbitrary objects,

It is also rather 'heavyweight' for a lot of situations.

There's another problem.  What if an exception object belongs to a class
that was declared inside a subprogram P, and no handler inside P catches
it.  Now an object has escaped outside the region of the program where
it makes sense.  Imagine, for example

    void foo(void) {
	char buff[4];
	class my_exception : std :: bad_alloc {
	    private: char *msg;
	    public : myexception(char *m) msg(m) {}
	};
	strcpy(buff, "fu!");
	my_exception e(buff);
	throw buff;
    }

This is not supposed to be correct C++, by the way, just to illustrate
the possibility.  C++ puts severe restrictions on classes declared
inside functions (which is a rather gross violation of one Stroustrup's
design rules for C++: allow nesting whenever it makes sense).  Ada,
however, doesn't have those silly restrictions, which means that
throwing an exception object out of the scope of its class would be a
possibility that would have to be blocked some way.

Lisp, of course, makes returning objects outside their lexical scope
_work_, so the problem doesn't apply in quite these terms to CLOS.

-- 
John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok

Re: Improving Ada Exceptions

[Wayne Magor]

My biggest gripe with Ada exceptions is that there is no indication in the
spec as to what exceptions a subprogram can raise (or propagate).

You cannot know for sure that *your* code is correct until you examine the
bodies of all the subprograms you call for "raise" statements.  You then
must examine all the subprograms that they call, and so forth.

Perhaps a tool is needed that does this type of analysis.  Then, at least
comments can be added to every subprogram spec indicating what exceptions
it could raise.  Knowing this, you should be able to create a tool that
tells you if any of your code is propagating exceptions that you didn't
expect to be propagating.  Then, if you don't want it to be propagated
you can handle it in your subprogram.

Recovering from unexpected exceptions is important in critical applications,
but it's difficult to achieve.

Re: Improving Ada Exceptions

[Samuel T. Harris]

Wayne Magor wrote:
> 
> My biggest gripe with Ada exceptions is that there is no indication in the
> spec as to what exceptions a subprogram can raise (or propagate).
> 
> You cannot know for sure that *your* code is correct until you examine the
> bodies of all the subprograms you call for "raise" statements.  You then
> must examine all the subprograms that they call, and so forth.
> 
> Perhaps a tool is needed that does this type of analysis.  Then, at least
> comments can be added to every subprogram spec indicating what exceptions
> it could raise.  Knowing this, you should be able to create a tool that
> tells you if any of your code is propagating exceptions that you didn't
> expect to be propagating.  Then, if you don't want it to be propagated
> you can handle it in your subprogram.
> 
> Recovering from unexpected exceptions is important in critical applications,
> but it's difficult to achieve.

If you compiler provides an ASIS (Ada Semantic Interface Specification)
then you should be able to produce such a tool.

I've used Ada 83 ASIS extensively, but have not dabbled with
Ada 95 ASIS yet. But that is the route I'd take. Alternatively,
you could get an Ada yacc grammar and do the lex/yacc or aflex/ayacc
kind of thing. I believe that is more work, but ASIS does have
a significant learning curve.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"