workshop on Exception Handling for a 21st Century Programming Language

workshop on Exception Handling for a 21st Century Programming Language

[Alexander Romanovsky]

Workshop on
    Exception Handling for a 21st Century Programming Language
    May 14, 2001, Leuven, Belgium

To be held at the
    6th International Conference on Reliable Software Technologies -
Ada-Europe'2001
    http://www.ada-europe.org/conference2001.html

As the complexity of modern software systems grows, so does the need
to deal reliably and efficiently with an increasing number of
abnormal situations. The most general mechanism for this is exception
handling, which is becoming a standard feature in modern languages.

A general exception handling mechanism should be well integrated with
the other features of a language and conform to its programming
paradigms. Increasing evidence from researchers and practitioners
indicates that the exception handling in Ada 95 does not adequately
reflect the whole range of programming paradigms supported by the
language. In particular, the exception handling model remains based
on Ada 83 while Ada 95 is object oriented. Furthermore, exceptions
and concurrency are, arguably, not well integrated. A task with an
unhandled exception dies silently, and one has to resort to
asynchronous transfer of control for passing exceptions
asynchronously between tasks. It is not clear that this solution
extends well into a distributed environment. Yet another problem is
the existence of anonymous exceptions.

New fault tolerance schemes based on existing exception handling
facilities have been developed in research environments. This is
important as it allows higher level abstractions providing more
advanced mechanisms to be introduced without impacting the language
definition.

The aims of the workshop are:
- to share experience on how to build modern systems that have to
deal with abnormal situations;
- to discuss how solutions to those needs can be developed employing
standard Ada features including the current exception handling
paradigm; and
- to propose new exception handling mechanisms / paradigms that can
be included in future revisions of the Ada language and also fit high
integrity language profiles for safety critical systems.

Participation to the workshop is limited to 25-35 individuals and is
by invitation upon acceptance of a submission. All types of
submissions are welcome: brief position papers, experience reports,
full research papers, etc. All papers will be made available to
workshop participants before the workshop. The workshop will include
talks based on the submitted papers and intensive shepherded
discussion sessions. The submissions and a workshop summary will be
published in Ada Letters.

Submissions should be sent electronically (preferable in ps or pdf
format) to Alexander Romanovsky:
mailto:alexander.romanovsky@ncl.ac.uk

Electronic submission:          January 31, 2001
Notification:                   March 15, 2001
Revised versions of papers:     April 15, 2001

Workshop co-chairs:
Alexander Romanovsky (U. of Newcastle)
Alfred Strohmeier (EPFL)
Andy Wellings (U. of York)

Workshop Programme Committee:
Bill Bail (MITRE)
Jörg Kienzle (EPFL)
Pat Rogers (Software Arts and Sciences)
Bo Sanden (Colorado Technical U.)
Anand Tripathi (U. of Minnesota)
Tullio Vardanega (ESA)
Thomas Wolf (Paranor)


Workshop web page:
http://www.cs.ncl.ac.uk/people/alexander.romanovsky/home.formal/eh-ada.html
_______________________________________________________________________

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

[Robert Dewar]

If you want people to be interested in participating in a
"workshop" like this, it is better not to give the impression
that it is being organized by people who have prejudged the
issues and have made up their mind. It sounds more like a
language lobbying effort to me than an objective workshop.

P.S. tasks going away silently on unhandled exceptions is
indeed a peculiar design decision, but its importance on
a scale of 0 .. 10 is about 0.2, why? because the fix is
completely trivial, just make sure that at the outer level
of every task type, you write:

   exception
      when others => ... do what you want here

Actually I think I should reduce the importance to 0.01, why?
because whatever the language did, you would need such a
handler anyway, since no default action is useful given that
the only way to communicate to other tasks would be by some
ayshcronous mechanism which is really out of the question here.

For my own taste, I would have said that an unhandled exception
in a task caused impl defined program termination, then those
who want the current semantics can have a handler saying

  when others => null;

but if that was done, then you would still need your own
handler for serious error handling.

This is probably the only non-controversial point you made,
but as I say, although it is probably easy to get consensus
on this point, it is of negligible importance. The other
issues which you present as having obvious conclusions do
not.

An open workshop might be useful, but please announce such
a workshop with questions, not answers!



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

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

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> For my own taste, I would have said that an unhandled exception
> in a task caused impl defined program termination, then those
> who want the current semantics can have a handler saying
> 
>   when others => null;

Me, too.

> but if that was done, then you would still need your own
> handler for serious error handling.

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").

- Bob

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

[Robert Dewar]

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.