Yes - and I think the current behaviour is how it should be. It's simple.
If you are doing something dangerous with exceptions, you'll also have to
program carefully. This might imply e.g. maintaining a hierarchy of error
severity, ensuring that no error is discarded without explicitly clearing
it, error logging, and similar stuff. Nothing of that should bother those
who don't need to care for such extreme cases. One of those simple things
you'd have to maintain is that no error handler masks a more severe error
(and this is nothing the system could [or should] do implicitly for you).
Errors in error handlers are always nasty, and certainly call for special
activities in critical applications. Nothing in the current system design
keeps you from implementing such behaviour exactly how you need it: catch
all errors in the handler and decide what should be done - saving the old
exception in case it should be propagated instead of the new one. Imagine
the reverse case, where the original error is no real problem, but in the
handler something terrible happens. You _have_ to do the dirty work, if a
program is critical enough that a short message, and a graceful shutdown,
are not good enough for you. Exceptions are tools for implementation, not
a global error handling policy.
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>