Hi John,
this is a belated reply, but I hope you remember the issue.
> Throwing an exception is a common (and very clean) means of
> aborting. This should not be prevented. One of the big
> advantages of catch/throw is that you can define the abort
> sequence at one location at the very top of the program
> where it makes sense.
I agree that C++ exception handling is a good mechanism.
> Aborting inside a single catch block tends to be a lot more
> elegant than, for example, buried calls to exit(). Cleanup
> and graceful exits tend to be easier from a top level
> location in the program.
I completely agree with you on this.
However, my concern is that it is possible for an application
to call the SCE-MI error handler from outside the normal call-chain
of the application. If the error handler throws an exception in
this case, the exception handler the user installed will not catch
the exception. An example of how this might occur is if the
implementation employs interrupt handlers, signal handlers, or
callbacks that execute with a different stack than the user's
application code.
If we want to maintain that it should be allowed for the user
to throw C++ exceptions in the SCE-MI error handler, then in the
example above, the implementation must somehow stash the error
information away and get back to a place where the error handler
can be called and throw the exception safely.
Ok, I am not suggesting to remove C++ exception handlingr as a
valid error reporting mechanism, I just wanted to point out some
less obvious consequences of this.
Per
Received on Mon Jun 21 19:10:19 2004
This archive was generated by hypermail 2.1.8 : Mon Jun 21 2004 - 19:10:20 PDT