question on exceptions

question on exceptions

[Michiel Perdeck]

Intro:
   This is one of several questions on Ada95 after reading the "Ada
guide for C/C++ programmers" from Simon Johnston. I am a fan of Ada
and I think that much (if not most) C/C++ programs should have been
written in Ada. I have, however, not been able to use Ada as much as I
would have liked. I have split my questions over a few messages so
that reactions may be given to individual questions.

Questions:
    Unlike an exception in C++, an Ada exception cannot carry any
extra information besides it's own name. In C++ you can have an
exception of a certain class e.g. SQL_Exception, and then put a
message in an exception when it occurs. The exception handler can then
use that information to write on a log-file or the like. It seems to
me that this is a more flexible concept (exceptions as objects) than
that of Ada (exceptions as scalar types).
I hope you can convince me that I'm wrong! What do you think?

Regards,
Michiel Perdeck
Michiel Perdeck
CMG AT Finance, Amstelveen, Netherlands
michiel.perdeck@cmg.nl
michiel.perdeck@tip.nl

Re: question on exceptions

[Laurent Guerby]

Michiel> Questions: Unlike an exception in C++, an Ada exception
Michiel> cannot carry any extra information besides it's own name. In
Michiel> C++ you can have an exception of a certain class
Michiel> e.g. SQL_Exception, and then put a message in an exception
Michiel> when it occurs. The exception handler can then use that
Michiel> information to write on a log-file or the like. It seems to
Michiel> me that this is a more flexible concept (exceptions as
Michiel> objects) than that of Ada (exceptions as scalar types).  I
Michiel> hope you can convince me that I'm wrong! What do you think?

   In Ada 95 an exception can carry a message (String), I believe this
functionality was added to help logging (an example of use you give).
Exceptions are not "scalar" types, look at Ada.Exceptions if you're
interested in Exception_Occurence objects.

   If you need more information to pass with an exception, may be it's
better to add a few parameters to your interface.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: question on exceptions

[Robert A Duff]

In article <E090uD.Kx6@tip.nl>, Michiel Perdeck <michiel.perdeck@cmg.nl> wrote:
>    Unlike an exception in C++, an Ada exception cannot carry any
>extra information besides it's own name.

Not true.  In Ada 95, an exception can carry some string information.
Look at package Ada.Exceptions.

>... In C++ you can have an
>exception of a certain class e.g. SQL_Exception, and then put a
>message in an exception when it occurs. The exception handler can then
>use that information to write on a log-file or the like. It seems to
>me that this is a more flexible concept (exceptions as objects) than
>that of Ada (exceptions as scalar types).

I agree that the C++ way (which also exists in many other languages,
such as Java, CLOS, CLU (I think?)), is better, because Ada restricts
this information to be of type String.  Also, these other languages
allow an exception handler to decide how finely to control the handling
-- handle all sorts of I/O errors, or just handle the file-not-found
error -- whereas in Ada, this decision must be made at the point of the
exception declaration(s).  Also, two kinds of things are needed in Ada
(exceptions and Exception_Id's), where one would suffice.  IMHO, that's
an ugly hack.

On the other hand, type String is often good enough -- your example of a
log file is easy to do in Ada.

>I hope you can convince me that I'm wrong! What do you think?

You're partly wrong.  ;-)

- Bob

Re: question on exceptions

[Michel Gauthier]

In article <E090uD.Kx6@tip.nl>, michiel.perdeck@cmg.nl wrote:

>>  [...]
>>  
>>  Questions:
>>      Unlike an exception in C++, an Ada exception cannot carry any
>>  extra information besides it's own name. [...]

Ada _can_ do this :
 - directly, in the case of String values,
 - indirectly, for every type with functions similar to
    the Image and Value attributes.

Attaching a String to a raise is a basic operation available
in the Ada.Exceptions predefined package.

For things other than String values, you can attach the Image
of what you want to attach. Inside the exception handler, you
can extract the message, and take its Value, which gets back
the initial value.

Caution : this works only if you can control that all raises are
correctly attached. Therefore, either you restrict such uses to
non-resusable parts, or you handle Constraint_Error possibly
caused by the back-parsing of the message.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone + 33 () 05 55 45 73 35  [or ~ 72 32]
fax +33 () 05 55 45 73 15  [or ~72 01]  
    no initial zero from abroad ! ! !
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: question on exceptions

[Do-While Jones]

In article <ws9iv7n2jtu.fsf@schonberg.cs.nyu.edu> guerby@gnat.com writes:
>Michiel> Questions: Unlike an exception in C++, an Ada exception
>Michiel> cannot carry any extra information besides it's own name. In
>Michiel> C++ you can have an exception of a certain class
>Michiel> e.g. SQL_Exception, and then put a message in an exception
>Michiel> when it occurs. The exception handler can then use that
>Michiel> information to write on a log-file or the like. It seems to
>Michiel> me that this is a more flexible concept (exceptions as
>Michiel> objects) than that of Ada (exceptions as scalar types).  I
>Michiel> hope you can convince me that I'm wrong! What do you think?
>
>   In Ada 95 an exception can carry a message (String), I believe this
>functionality was added to help logging (an example of use you give).
>Exceptions are not "scalar" types, look at Ada.Exceptions if you're
>interested in Exception_Occurence objects.
>
>   If you need more information to pass with an exception, may be it's
>better to add a few parameters to your interface.
>
>-- 
>Laurent Guerby <guerby@gnat.com>, Team Ada.
>   "Use the Source, Luke. The Source will be with you, always (GPL)."

Please allow me to expand on the notion of "adding a few parameters to
your interface."  It is a technique that I have found very useful.

Where I work there are several radars with unique data interfaces (which
are programmed in assembly language) that send data to a FORTRAN program
that gathers data packets from many radars and puts them in a large block,
sends this block to another computer (programmed in C) that broadcasts
modified data blocks to my display program (written in Ada 83).  There is
no built-in error checking done by the assemblers, FORTRAN, or C
compilers, and precious little error checking explictily done by those
programmers.  Consequently, my program received a lot of bad data during
the initial integration phase. 

Since I had taken the trouble to define special types for the data packets
and blocks of data packets (rather than just treating them as arrays of
integers, like the assembly language, FORTRAN, and C programs did), the
Ada compiler did some automatic checking for me, and immediately found
errors in the data that had gone undetected for years by the previous
display program.  (The previous program, written in assembly language,
just displayed incorrect positions and nobody realized it.)

The automatic error detection was done in the RAW_DATA_PACKET package
(which was responsible for converting the arrays of integers into records
of the proper type).  It raised an exception called
RAW_DATA_PACKET.BAD_PACKET whenever it found a bad packet. 

As has been pointed out, Ada 83 exceptions have no parameters.  That isn't
really a problem.  I simply save the current data block and the current
value of the index before trying to decode each packet in the block.  I
included functions that return the current data block and the current
index in package specification of RAW_DATA_PACKET. 

I programmed the display software so that whenever BAD_PACKET is raised, 
the exception handler calls these two functions to get the bad block and 
the pointer to the offending value.  It displays an alarm on the screen, 
and writes the bad block (in hexadecimal ASCII) to a text file, with ">>>" 
pointing to the bad value.

The upstream programs have fixed their problems, so I don't see this 
exception very often any more.  (It does usually pop up the first time 
somebody tries to integrate a new radar with our test range, however.)  
But when it used to happen regularly, it gave us all the information we 
needed to instantly diagnose the problem.

The moral of the story is that the exception is simply a flag that tells
you something has gone wrong.  If you take care to save the pertinent
values before the exception is raised, and if you include a mechanism to
retrieve those values when an exception has been detected, you have all
the information you need. 

Do-While Jones

-- 
            +--------------------------------+
            |    Know                 Ada    |
            |        [Ada's Portrait]        |
            |    Will              Travel    |
            | wire do_while@ridgecrest.ca.us |
            +--------------------------------+

Re: question on exceptions

[Robert A Duff]

In article <55l00n$alv@ash.ridgecrest.ca.us>,
Do-While Jones <do_while@lo-pan.ridgecrest.ca.us> wrote:
>The moral of the story is that the exception is simply a flag that tells
>you something has gone wrong.  If you take care to save the pertinent
>values before the exception is raised, and if you include a mechanism to
>retrieve those values when an exception has been detected, you have all
>the information you need. 

In a multi-tasking program, you would probably want to store this
information in a task attribute.

I still think that some other languages do it better (more type safety)
than Ada.  What I want is to declare what sort of information is
attached to a particular exception name.  Then the handler knows what
type of information is attached, and references to this information can
be type checked.  C++, Java, CLOS, etc have this capability.

While your solution works, it isn't quite as safe.  For example, a
handler for X might try to grab information that is only associated with
exception Y.  Or somebody might evilly call the function to get the
extra information when not in an exception handler at all, when the
information isn't available.  Or an exception handler might call a
procedure that internally raises-then-handles an exception, thus
overwriting the information -- you have to be careful to grab the
information before doing anything else in the exception handler that
might invalidate the information.  You could write the
information-getting function to detect these errors at run time, but it
would be slightly nicer to have compile-time error detection.  You can
write comments in the code explaining the proper use of this function,
but it would be slightly nicer to have that information encoded in the
program itself, in a standard way.

By the way, during the design of Ada 9X, it was suggested that we have
functions for querying things like the Current_Exception_Name and
Current_Exception_String.  However, the design team rejected this idea
for the reasons explained above -- presumably the semantics of calling
these at the wrong time would be "erroneous", which is bad.  My main
complaint about the Ada 95 design for this stuff is that the information
associated with an exception *must* be of type String.  I suppose you
can encode whatever information you want in a string, but not with type
safety.

- Bob

Re: question on exceptions

[Tucker Taft]

Robert A Duff (bobduff@world.std.com) wrote:

: ... My main
: complaint about the Ada 95 design for this stuff is that the information
: associated with an exception *must* be of type String.  I suppose you
: can encode whatever information you want in a string, but not with type
: safety.

Perhaps Bob and I have different memories of this issue.
An Ada 95 exception occurrence can conceptually carry any information
of any type.  

The only kind of information for which we specified a standard 
set of operations was type String, largely because in
a "when others" clause, String is about all you could usefully presume.

On the other hand, there is nothing precluding an implementor, or
the implementor "community," from defining additional packages for allowing
additional kinds of information to be carried along with an exception
occurrence.  In particular, such a package might define a root tagged 
type for carrying information (e.g. type Root_Exception_Info is tagged 
private;) which in the root type only carries one string, but then allow 
a user to extend this type to carry any other kind of information.  
In an exception handler, membership tests could be used to determine 
what sort of additional information was passed along.

Personally, I had always envisioned that these new packages would appear
over time, but perhaps we should have given more of a push for them
in the Ada 95 RM.

: - Bob

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

Re: question on exceptions

[Robert Dewar]

Bob Duff says

"By the way, during the design of Ada 9X, it was suggested that we have
functions for querying things like the Current_Exception_Name and
Current_Exception_String.  However, the design team rejected this idea
for the reasons explained above -- presumably the semantics of calling
these at the wrong time would be "erroneous", which is bad.  My main
complaint about the Ada 95 design for this stuff is that the information
associated with an exception *must* be of type String.  I suppose you
can encode whatever information you want in a string, but not with type
safety."

I see no reason why these could not be functoins which can only be called
within a handler, checked statically by the compiler. This is how GNAT
implements the DEC Current_Exception package (which has these semantics).

Re: question on exceptions

[Robert A Duff]

In article <E0I7zK.E4x.0.-s@inmet.camb.inmet.com>,
Tucker Taft <stt@houdini.camb.inmet.com> wrote:
>In an exception handler, membership tests could be used to determine 
>what sort of additional information was passed along.

Yeah, I also envisioned such implementation-defined stuff.

But I want to declare the type of the attached information at the point
of the exception declaration, so that *handlers* can know for sure (at
compile time) that every *raise* of, say, The_Sky_Is_Falling will attach
(say) the current color of the sky.

The membership test isn't so awful, with appropriate comments at the
point of the exception declaration, but it *could* be done at compile
time.

- Bob

Re: question on exceptions

[Tucker Taft]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: Bob Duff says

:> "By the way, during the design of Ada 9X, it was suggested that we have
:> functions for querying things like the Current_Exception_Name and
:> Current_Exception_String.  However, the design team rejected this idea
:> for the reasons explained above -- presumably the semantics of calling
:> these at the wrong time would be "erroneous", which is bad.  

: I see no reason why these could not be functoins which can only be called
: within a handler, checked statically by the compiler. This is how GNAT
: implements the DEC Current_Exception package (which has these semantics).

There would still be some possible ambiguities associated with such 
functions.  What are their semantics when there is an exception raised and 
then handled in some statement within the handler, but preceding 
the call to one of these special functions?  Does it report the
most recent exception raised, or does it report the exception being
handled by the current handler?  Also, what happens if you rename
such a subprogram?  Does the renaming retain its special status?

I presume we generally agree that having a namable exception 
occurrence object makes the semantics clearer, and gives the
programmer a bit more flexibility.

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

Re: question on exceptions

[Robert Dewar]

Bob Duff says

"Think about implementation difficulty.  One reason people advocated a
"plain old function" was to make it easy to implement.  But if that
function has special rules, then the compiler has to special-case it
anyway, so it's probably even *harder* to implement it."

Absolutely! Implementing the DEC package Current_Exception which is, on the
face of it, a collection of "plain old fujnctions", is a major pain, and
the front end of the compiler has to know all sorts of special things 
about the functions in this package.