🚀 go-pugleaf

: > c) One could also use a stack of exceptions: The last thrown exception
: >    has to be handled next.

: That would wind up being clumsy at best, and generally unworkable.

Interesting idea.  Just to remind myself, this is *only* so we
can throw exceptions in the destructor, right?

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.  

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):

Thus, every "catch" today is potentially using "the buck stops here" 
approach.  To do that with an exception stack, every catch must be 
in an infinite loop.

  try 
  {
    foo();
  }
  while_catchable   // (Making up syntax)
  {                 // While we are still catching an infinite
    catch(int i)    //   number of exceptions from that stupid
    {               //   foo() call.
      ...do stuff.
    }
    catch(X& x)
    {
      ...do stuff.
    }
    catch(...)
    {
      ...do stuff.
    }
  }

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

--charley




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