🚀 go-pugleaf

> ==========John Max Skaller, 11/20/95==========
 
> What's more, the committee has taken special pains to
> add an extensions late in the process to ensure
> memory can be deallocated correctly if a constructor 
> invoked by a new expression fails. So called "placement
> delete" now exists to enable leak proof programs
> to be written. In addition, there is a flag for checking
> if there is a current unhandled exception, for the
> same reason -- so you can avoid throwing an exception
> (which would otherwise cause immediate termination,
> not a suitable action in some embedded or
> continuously running systems).

Such a flag can be of limited help, given the current
rules about only one exception at a time.  But that is
a bandaid rather than a real solution to the fact that
multiple exceptional conditions do, in practice, overlap
in the real world situations.  When you allow only one,
the first one to go off is it and you either completely
suppress the other exceptions which may be more serious
and need different handling at each catch level, or
you must do your own real mechanism that records
the real world multi-exception track behind the
exception mechanism's back while using one exception
as a token to get the frames and catch layers
unfolded.  That may require you to encase "outside"
stuff  to convert to your scheme.  Has anyone gone
this route to an extent that would provide useful
fodder for the standard, or am I likely to forge
new paths if I get the kind of work I speculate
may be in the offing in the near future (I am a trailing
spouse and am about to find myself in a new situation)?

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. ]