Re: exception systems

["Guillermo J. Rozas" <gjr@martigny.ai.mit.edu>]

I like Will's analysis of the status of exception handling proposals
and the classification of the purposes to which exception handling may
be put.

I also agree with concentrating on the higher numbers in his
classification (vs. the lower ones).

However, I question whether we should couple asynchronous interrupt
delivery with synchronous exception handling.

Any asynchronous interrupt delivery system (timer, user interface,
etc.) is going to be completely library/implementation specific.

Assuming that any exception handling proposal accepted has a way to
construct/generate/declare new exception types/classes/whatever, and a
way to signal/raise them from arbitrary code, it should be straight
forward for asynchronous interrupts to be reflected onto the exception
handling mechanism if that is desired, thus I'm not sure that we need
to worry about them beyond keeping these requirements in mind.

A different issue is whether we want to talk about agreeing to
interfaces for such common asynchronous events so that implementations
that provide them can do so in a compatible way, while not forcing
other implementations to provide them at all.

Thus I think that the right area to concentrate is levels 4 and 5.

Note also that once an exception handling mechanism is in place, we
might re-evaluate the issue of whether certain erroneous situations
should have errors signalled or not.