Topic: nested exception processing


Author: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Date: Tue, 17 May 1994 18:00:09 GMT
Raw View
dag@control.lth.se (Dag Bruck) writes:

>>>>>> "D" == David Sachs <b91926@fnclub.fnal.gov> writes:
>
>D> Does the c++ standard allow nested exception processing?
>
>Yes.

The wording in the ARM (15.2, page 358):

 "A throw-expression with no operand rethrows the exception
 being handled"

seems to assume that there is only one exception being handled
at any given time.  Has this wording changed in the latest ANSI/ISO
working paper?

--
Fergus Henderson - fjh@munta.cs.mu.oz.au




Author: dag@control.lth.se (Dag Bruck)
Date: 18 May 1994 06:00:04 GMT
Raw View
>>>>> "FJH" == Fergus Henderson <fjh@munta.cs.mu.OZ.AU> writes:

FJH> The wording in the ARM (15.2, page 358):

FJH>  "A throw-expression with no operand rethrows the exception
FJH> being handled"

FJH> seems to assume that there is only one exception being handled at
FJH> any given time.  Has this wording changed in the latest ANSI/ISO
FJH> working paper?

Bill Gibbons (Taligent) and some others did a good job on figuring out
what nested exceptions mean and, in particular, how to phrase it.  I
would expect that the next version of the working paper has some new
wording.

     -- Dag




Author: b91926@fsgi01.fnal.gov (David Sachs)
Date: 18 May 1994 13:03:01 -0500
Raw View
dag@control.lth.se (Dag Bruck) writes:

>>>>>> "FJH" == Fergus Henderson <fjh@munta.cs.mu.OZ.AU> writes:

>FJH> The wording in the ARM (15.2, page 358):

>FJH>  "A throw-expression with no operand rethrows the exception
>FJH> being handled"

>FJH> seems to assume that there is only one exception being handled at
>FJH> any given time.  Has this wording changed in the latest ANSI/ISO
>FJH> working paper?

>Bill Gibbons (Taligent) and some others did a good job on figuring out
>what nested exceptions mean and, in particular, how to phrase it.  I
>would expect that the next version of the working paper has some new
>wording.

The Borland C++ 4.0 compiler and its libraries allow multiple
exceptions to be in the state of "being handled" at the same
time. Does this make BCC4 non-conforming?




Author: dag@control.lth.se (Dag Bruck)
Date: 19 May 1994 06:30:39 GMT
Raw View
>>>>> "D" == David Sachs <b91926@fsgi01.fnal.gov> writes:

D> The Borland C++ 4.0 compiler and its libraries allow multiple
D> exceptions to be in the state of "being handled" at the same
D> time. Does this make BCC4 non-conforming?

I haven't read that part of the manual, but seems to me that "being
handled" implies nested exceptions (which are supposed to work).  I
think we used "caught" instead of "being handled" in the standards
committee, but that is just a question of terminology.

I.e., an exception is "caught" when you enter the appropriate
catch-clause, and "handled" when you leave the catch-clause.

Nested exceptions are difficult to understand for most people, it's
like recursion only worse.  I would recommend people starting to use
exceptions to go for the simple approaches.  When things go wrong, the
program had better be right.

     -- Dag




Author: dag@control.lth.se (Dag Bruck)
Date: 11 May 1994 17:41:40 GMT
Raw View
>>>>> "D" == David Sachs <b91926@fnclub.fnal.gov> writes:

D> Does the c++ standard allow nested exception processing?

Yes.

An example is the following: we're unwinding the stack during
exception processing.  In the destructor for one of the objects on the
stack we call a function that throws an exception; this is a nested
exception.  This is ok if we handle the exception locally, for
example, in the destructor we were executing.

     -- Dag




Author: b91926@fnclub.fnal.gov (David Sachs)
Date: 10 May 1994 19:29:38 GMT
Raw View
Does the c++ standard allow nested exception processing? The tests I have done with Borland C++ 4.0 have all succeeded.

Bye "nested exception processing", I mean the COMPLETE processing of an exception ( try block calls something that throws and exception, which is caught by the corresponding catch block ) while a previous exception has not been completely preocessed yet.