🚀 go-pugleaf

> ==========Tom Payne, 1/19/96==========
> 
> Dick Menninger (Dick.Menninger@daytonoh.attgis.com) wrote:
 
> Good analysis, but I'm unclear about the conclusion.  Functions called
> by signal handlers should be allowed to throw exceptions.  If,
> however, the signal handler itself throws an exception or fails to
> catch one thrown to it, then the situation seems analogous to the base
> function of a thread throwing an exception or failing to catch one
> thrown to it.  Shouldn't we consider that a bug?

If a thread in a multi-threaded environment throws an
uncaught exception, something must happen.  That
something also applies to the signal handler's uncaught
exceptions unless another, more specific mechanism
is supplied.  For instance, since a C++ wrapper to the
signal handler is needed to determine this has happened,
the wrapper could have a standard default action function
that can be overridden by the app.  The language has
set the precedent of defining how uncaught exceptions
behave is some circumstances.  Once that door is open,
the language has to do it in the rest of them.

The above should also work in single-threaded environments,
as well.  It is just more obvious when thinking in terms
of multi-threaded environments.


Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]