Re: workshop on Exception Handling for a 21st Century Programming Language

[Robert Dewar <robert_dewar@my-deja.com>]

In article <wccaebv37c0.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Right, but only for *serious* error handling.  For
run-of-the-mill
> desk-top non-embedded programs, killing the program might be
just fine.
> After all, that's the default behavior you get when you don't
have tasks
> (by "default" I mean "no handlers").


Probably we should have fixed this in Ada 95. I wonder if
there is any other program in the world other than junk ACVC
tests that relies on tasks silently going away on an exception.

It would have been a VERY mild change to the language, and
definitely beneficial. I rememeber one of the hardest bugs
we dealt with in Ada Ed was a case where an In-Out parameter
was uninitialized, and Ada Ed of course detected all cases
of uninitialized parameters (it was one of those cases where
the parameter was not touched by the function, but from a
semantic point of view, the uninitialized value was still
read and written back).

Ada/Ed thus raised Program_Error on the call. This caused the
task to die with an unhandled exception, which caused other
tasks to die silently in a cascade of tasking_error exceptions,
and finally, with no tasks left, the main program failed.

Very nasty to debug :-) That was the point at which we added
an option to output messages when a task dies from an unhandled
exception. We are actually making this the default behavior
for GNAT. It is not even clear that it is improper to generate
such messages (the RM says that Text_IO can cause messages to
appear on standard_Error, but it is not clear that it forbids
other warnings to appear there ...



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