🚀 go-pugleaf

> ==========Charley Bay (Contract), 12/2/95==========
 
> Interesting idea.  Just to remind myself, this is *only* so we
> can throw exceptions in the destructor, right?

More than that.  Anything called by the destructors or catch
code, including any objects constructed, need the flexibility
to throw exceptions.  Otherwise, you find that the tentacles
of this limitation manage to propagate out into the design.
It may even tip the scales to where setjump/longjump have
to be used.
 
> If we go this road, It sounds to me like all our "catch" blocks are 
> *really* going to have to be infinite loops, or we can't trust
> that they really caught the problem we were looking for.  After
> all, what's a catch for?  Catching the situation at the lowest level
> where we know what's going on, but the highest level where we have
> some authority to handle it.  

Well, they could be potentially infinite if you allowed catch
code to rethrow an exception that it then still sees to process.
There may be reasons to retry this way.  There is the case of
exceptions thrown by something called by the catch code or
by objects it needs to create.  There may need to be try blocks
in the catch or something related.  I did not say this would
be easy, only that it seems to be necessary to get it to
be useable.
 
> We only catch because we think we can solve the problem.  If there
> is a (potentially) infinite number of exceptions from each call,
> then NO catch block can clear anything unless it keeps looking
> for exceptions at that level (where it is better able to determine
> context than any other point on the system):
 
You only catch and fully process those that are appropriate.
It can clear an exception if it handles that exception.  But
that does not mean it is necessarily done.  The catch code
could also decide that some catch code further out should
handle the rest of an exception , possibly after doing some
partial processing.  

[stuff deleted]
 
> My only issue with an exception loop is that arbitrarily catching
> exceptions until there are no more completely hides what the heck
> went wrong in the first place.  How to gauge the severity of the
> first, second, third exception?  It will take some pretty serious
> logic just to confirm what exception went first, second, third.

There are two situations here, at least.  The order of exceptions
does not imply importance or relatedness at all.  That is one of
the key issues why you need a mechanism that allows multiple
exceptions.  If you don't have it in the language, you have to
do it behind its back when you cannot tollerate an exception
of lower importance keeping you from "throwing" one of higher 
importance.  What winds up happening is that you have your
own THROW code and you cannot use anything that might
use "throw" outside of your THROW.  You reimplement a lot
of stuff that you should never have to reimplement.

The second issue is that you may need to see the set
of exceptions (or subsets of them) at the same time in order
to make the right decisions.

> This level of complexity in MERELY exception processing is beyond
> reasonable, IMHO.  The design should not require this level of
> super-human exception processing effort.

So, when we have harder problems than "simple" application
development, we should pick another language?  I have found
that even in application development (and in other problems)
handling errors has a major impact on design and code.  A good
exception mechanism REDUCES the impact on (distortions of)
the other parts of the design and code.

A lot of that "buggy" code out there is really code that
ignores proper error handling.

This problem is as hard as it is.  Ignoring that by pretending
it is simpler than it really is is just a distortion.

I suspect that with the schedule pressures of the
standardization effort, only a limited improvement
is practical.  But something that allows multiple
exceptions to be muddled through, and so, allows
the use of stuff (including other peoples' stuff)
that might throw an exception while doing what really
needs to be done, is needed to make this tollerable
and to get experience to guide the next round.
I see that as fixing something that is broke.

> --charley

[By the way, thanks for asking some useful questions.]

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