🚀 go-pugleaf

Dick Menninger (Dick.Menninger@daytonoh.attgis.com) wrote:
: You only catch and fully process those that are appropriate.
: It can clear an exception if it handles that exception.  [snip]
: 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.  

Ok, I like this.  I feel much better.  So, would the following
exception stack be possible under this proposal?

   Exception Stack (ALL EXCEPTIONS GENERATED AT CALLING LEVEL 4+).
   (int)exception            --must be processed at calling level 1.
   (Dog&)exception           --must be processed at calling level 3.
   (double)exception         --must be processed at calling level 1.
   (PotatoPeeler&)exception  --must be processed at calling level 2.

If so, then I absolutely agree:  This would undeniably clean
up a lot of exception handling code.  (Multiple simultaneous
exceptions would be a very good thing that I would actively use.)

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

How do we gauge priority, then?  I assumed order of processing must
be the reverse of order generation, and that the last exception
generated must be serviced before the previous exception (after
all, it was an exception in the servicing process for a previous
exception).  I was assuming this was a stack frame limitation.

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

Wow.  That would certainly be impressive, and possibly very useful.
However, don't they still need to be serviced in reverse order from
generation?  Don't we have implied relatedness within a stack of 
"int", "Banana", "int" exceptions?  I would think we must order 
the two "int" exceptions somehow.

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

Agreed.

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

Aw, we both know that's because code with exception handling
is twice as much work as code that ignores problems.  :-)  :-)

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

I must agree with this statement.  I do admit that
an execution of "void unexpected(void)" is a rather in-elegant
solution to a situation that will obviously occur quite
frequently.

When reading the standard, I was continuously presented with
the ancillary (implied) goal of "no limits".  Handling multiple
exceptions seems consistent with that, and I do admit it could
be tremendously advantageous.

I'm still trying to figure out how a "catch" block is going
attempt to handle three exceptions simultaneously, though...
Would it simply be implied that the catch(...) would iterate
once for each exception?  If so, what if it decides to re-throw 
the exception to a higher level?  Does it come back for the 
other two exceptions?  The compiler venders are going to 
hate us.  :-)  :-)  :-)

--
--charley                              #include <stdisclaimer.h>
charleyb@gr.hp.com    -or-    charley@agrostis.nrel.colostate.edu




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