Ada exception limitations

Ada exception limitations

[jehamby]

Recently I've been revisiting Ada after a long absence.  My main gripe
with C++ is its cryptic syntax and excessive complexity.  I really like
Java, the language, but compilers from Java to native code are
immature, JIT interpreters are still too slow for some tasks, and I'm
not too fond of the class library or the difficulty of interfacing
native code to Java through JNI.

Anyway, Ada 95 seems to be the answer to many of my complaints, yet one
thing I dislike is that I've noticed some weaknesses in its exception
handling capabilities compared to what I've grown used to with Java.
For example, a current project I've written in Java (a database server)
has an exception hierarchy like this:

public class ABCException extends java.lang.Exception {
    private int errCode;
    public ABCException() {
	super();
	errCode = 0;
    }
    public ABCException(int errCode, String s) {
	super(s);
	this.errCode = errCode;
    }
    public int getErrorCode() {
	return errCode;
    }
    public String toString() {
	return "E" + errCode + ": " + getMessage();
    }
}

Then I have subclasses of ABCException for different types of
exceptions that can be thrown inside the code.  For example,
ABCUserException, ABCInternalException, etc.  Within a subclass, the
particular exception is defined by a unique error code, which is sent
to the client, who can look it up and print an ASCII error message to
the user.  I have a logging function on the server which stores the
error message, along with the client that generated it, as well.

I'm not planning to port this to Ada, but if I were to, I think the
mapping of my exception classes to Ada exceptions would be the biggest
weakness.  In particular, I see two areas where Java (and C++) beat Ada
for exception handling:

#1:  No hierarchical exceptions.  AFAIK, I can't declare an Ada
exception as a child of another exception, and then catch both
exceptions with a single 'when' clause.  I wouldn't want to collapse
all of my custom exceptions down to a single Ada exception, but neither
putting a long list of when clauses into every exception handler, nor
using 'when others' for everything, appeals to me.

#2:  No ability to associate user data with exceptions.  I know it's
possible to raise an exception with an associated string message, and I
could use this to pass the error number as a string, but this seems
kludgy.

If I'm wrong about either of those counts, I'd really like to know.  I
suppose, had I originally written this program in Ada, I probably would
have done things differently, perhaps using a single exception type for
the entire program, and storing the particular error code in a thread-
local variable so that it could be sent to the client.  However, I
rather prefer the way it ended up in Java.  My question is:  have any
attempts been made to update the standard to make Ada exception
handling more like C++ or Java?  Does GNAT offer any extended
capabilities in this area?

Thanks,
-Jake


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada exception limitations

[Stanley R. Allen]

jehamby@lightside.com wrote:
> 
> #1:  No hierarchical exceptions.  AFAIK, I can't declare an Ada
> exception as a child of another exception, and then catch both
> exceptions with a single 'when' clause.  I wouldn't want to collapse
> all of my custom exceptions down to a single Ada exception, but neither
> putting a long list of when clauses into every exception handler, nor
> using 'when others' for everything, appeals to me.

This is a nice feature to *use* in Java and C++, but if I'm not mistaken,
it generally carries a heavy runtime burden.  For a real-time language
like Ada, the expense of throwing exceptions as objects, and especially
catching and distinguishing among them in handlers was probably considered
too great (a language designer in this group may chime in and tell you
more; Java was not around during the definition of Ada 95, but C++ was
and I'm sure they'll tell you that they looked at this issue carefully).

> #2:  No ability to associate user data with exceptions.  I know it's
> possible to raise an exception with an associated string message, and I
> could use this to pass the error number as a string, but this seems
> kludgy.

One of the developers in my organization always creates an Image and
Value function for every class package he writes.  Respectively, these
create a string which represents the value of the (private) type, and a value
from the string representation created by Image.  He generally uses these
for debugging, but the idea could be applied to make an 'exception object'
in Ada 95.  You could use the package Ada.Tags to generate a string 'type'
distinguisher as the prefix of the string created by the Image function
of the private type.

Like you said, it's a bit of a kludge to convert between strings and values
but it can allow some of the expressiveness of the C++/Java model.

-- 
Stanley Allen
mailto:Stanley_R_Allen@raytheon.com

Re: Ada exception limitations

[Ehud Lamm]

See my question about "filterring exceptions" (from my "extra exercies"
page).
Direct link: http://www2.cybercities.com/e/ehud/ada/ex_filt.html

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: Ada exception limitations

[James S. Rogers]

>#2:  No ability to associate user data with exceptions.  I know it's
>possible to raise an exception with an associated string message, and I
>could use this to pass the error number as a string, but this seems
>kludgy.


Actually, this is a lot less kludgy from an efficiency point of view.
The package Ada.Exceptions allows you to do a number of very
useful things with exceptions. The other possibility, of course, is to use
a lot of different exceptions, which can get kludgy.

Each subclass can raise exactly the same exception, while providing
a unique message in the Raise_Exception procedure call. Parsing
a string can be a lot simpler and less kludgy than attempting to
"catch" a C++ exception when you do not know its type or class. In
fact, the difficulties with using C++ exceptions generally lead to two
different results. The first and most common is to refuse to use them
at all. The second is to standardize on a single exception class
( commonly strings ) to communicate exception information. The first
case is regretable, and not what I want to see for Ada. The second
reduces C++ exceptions to Ada exceptions.  I do not see any reason
for Ada to change to C++ style exceptions.

Look into the wonderful possibilities using Ada.Exceptions and being
able to "log" exceptions using arrays or lists of Exception_Occurrence.
This gives you most of the more useful aspects of being able to define
your own exception class.

Jim Rogers
Colorado Springs, Colorado

Re: Ada exception limitations

[Laurent Guerby]

jehamby@lightside.com writes:
> [...] My question is: have any attempts been made to update the standard
> to make Ada exception handling more like C++ or Java?  Does GNAT
> offer any extended capabilities in this area?

As you found out, the Ada language designers ruled out the possibility
of attaching data to an exception, they felt that a string was enough
for most uses, and since an implementations is allowed to place a
static restriction on the length of the string, it can be efficient
(and trouble free from a semantic point of view, no risk of having the
exception object constructor raising an exception, etc..).

In one project I'm working on, we use exceptions when we find out some
problem with the user input, and the last layer is expected to report
a clear and informative message to the user, and this means that the
length of the message is likely to exceed the built-in limit for
excepion message length of our compiler (GNAT with support from ACT
Europe).

We handle the issue with a dedicated "Errors" package that provide
three entry points:

procedure Error (Message : in String);
procedure Error (E : in Exception_Occurrence; Message : in String);

procedure Purge_Error (E : in Exception_Occurrence;
                       X : out Some_Stack_Of_String_Data_Structure);

The idea is that when there is a problem, the code calls 

if Ooops then
   Error ("aie aie aie");
end if;

which allocates an internal id, store the message in a table
indexed by the id, and raise an exception with the id encoded in it.
You can add context during the propagation by calling the second entry
point:

exception
   when E : others => Error (E, "problem while computing stuff");

If Error finds the id in E, then it appends the message, otherwise it
creates a new id, store the compiler message as first entry (prefixed
with "internal error"), and raises the exception with the encoded id.

Purge_Error is used by the top layer to get the message to the user
(it could be a disk log), and has the effect of freeing data
associated with the exception. If you don't purge, you'll leak some
memory.

You'll have not to forget protecting the error data against concurrent
access in a multitasking environment. If you're working in a
distributed Annex E setup, you might have to encode node information
in the message, otherwise, you can extend your communication protocol
to transmit the exception information and continue propagation on the
receiving side.

Note that the main assumption here is that you use exception for
*exceptional* and unpredictable cases. (There is only one place in our
code where we recover from an exception, and it is for covering up
known numerical instabilities.)  The rule we follow is that if there
are likely error outcomes, we use an explicit output or result
parameter for it, not exceptions. Note that this helps debugging
because when we're after a problem, the first exception raised points
directly to the problem.

Your mileage may vary.

Hope this helps,

--LG

Re: Ada exception limitations

[jehamby]

Thanks to you, and the other people who replied, for your suggestions!
I can see now how the limitations of Ada exceptions wouldn't necessarily
have prevented me from implementing a system just as powerful as what I
created using Java exceptions.

-Jake


Sent via Deja.com http://www.deja.com/
Before you buy.