🚀 go-pugleaf

> ==========Herb Sutter, 11/21/95==========
 
> PROBLEM: Basic Inconsistency (Ctors and Dtors and Exceptions)
 
[discussion focused on ctors and dtors deleted]

Actually, the inconsistency seems more basic, though
what was said seems true.  Any code, including code
called in ctors, dtors, and exception handlers or implied
execution in the companion unwinding that must occur
should be capable of being common use code that can
want to throw exceptions independent of any other
exception already thrown.  From an application design
viewpoint, THIS IS NOT A RACE with the first exception
thrown winning and the rest swallowing their "pride"
and going quietly away.  There may be differences in
the importance of the exceptional conditions that are
found, but there is never any plausible reason that
could be given that the more important one will be
found first or that NOT being able to throw one makes
sense (it seldom does in any high availability/reliability
system design).  Even if two exceptional conditions
are of equal importance or the more important gets
thrown first, it does not seem to be very plausible
that swallowing only the first makes much sense.

Exceptions provide a control paradigm in for readily
backing out of portions of call stacks that allows
some disciplined use of call frames for data.  But
the current scheme seriously limits it useability.
Certainly we do not want to go back to the "globals
and heap only" approach necessitated by a
setjump/longjump approach.  But the current scheme
is almost as distorting of design by forcing a one
at a time design and not giving any good means
of insuring that any libraries used will gracefully
fit into that.  Yet it forces them to be used.
The door has been opened, but now you have to
go all the way through.

> PROPOSAL: Allow Multiple Simultaneous Exceptions

[ An inadequate proposal is deleted ]

I like the sentiment, but the details don't make
the grade.  First the possible multiple exceptional
condition cases need to be more accurately delineated.
Then the handler cases need to be matched up with them.
First, there may be unrelated exceptional conditions that
occur in the same window (window meaning
additional conditions need to be detected and raised
before some other condition has been handled).
Second, there may be similar but distinct exceptional
conditions that occur in the same window.  Third,
there may be separate detections of a common
exceptional condition.  Each of these may have its
own needs.

In the third case, it may be much easier to write
software if you could say something to the effect of
"throw this if it is not already thrown."  Obviously,
determining the identity for "already thrown" is the
key issue.  But here the needs are on the throw side.

In the second case, the exceptions need to be
distinguishable at throw time yet are likely to need
handling by the same handler or sequence of handlers
as you unfold.  Here, the handler may successfully
handle one subset and need the throw a remaining
subset.  Some may even fit part of the first case as
discussed below.

In the first case, you have two kinds of handler
situations: single handlers that handle unrelated
exceptional conditions and cascades of handlers
that handle various subsets of them, both of these
having the potential of successfully handling subsets
and rethrowing other subsets.  The order of looking
at the exceptional conditions may matter.  [cascade
is used in the sense of multiple catches for a try.]

These are the static cases.  That is, these are the
cases where the appilcation exception handling
is fixed at compile time.  I bring this up as a distinction
as I also see a possible need for runtime exception
handling binding.  However, compared to the static
case this is a frill where a good solution for the static
case is a necessity.

A library may want to establish base level handling
of its exceptions at the outer call layer to insure that
basic handling will happen if the calling application
does none.  This would force the unwinding of the
call frames, which may be important to the library's
provided service, and would then allow the basic
exception code specified by the library to be called
at the tail end.  This is dynamic in the sense that
the library may need to establish this when called,
particularly if the linkage to it is created at runtime
with use then distributed.  If the application does
"handle" the exceptional condition, the library can
get notified via the destructor call for the exception
instance and it may need to rethrow if it was not
really handled.

So, I tried here to outline the real problem as I see it.
I feel that much of the squirming going on now with
respect to exceptions is because the current mechanism
in woefully inadequate in fundamental ways.  The rest,
of course, is due to partial shock at the implications
of really dealing with exceptional conditions and partial
denial in most people's design and code.  An amazing
amount of code never checks for errors since that
would "distort" the design too much.  Taking a major
part of that distortion away is what the exception
control paradigm should do (making this excuse
as lame as feasible), but it has to solve the full problem
to be truly useable.



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