🚀 go-pugleaf

kanze@gabi-soft.fr (J. Kanze) writes:

>Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
>|> schuenem@informatik.tu-muenchen.de (Ulf Schuenemann) writes:
>
>|> >How about saying that dtors have an empty exception-specification 
>|> >(either by default or always) ?
>
>|> How does that help?
>
>|> >Then there are 3 cases possible:
>|> >- The dtor causes no eception.
>|> >- The dtor catches all exceptions and continues - save,
>|> >  but what happens to client-provided exception handling ?
>|> >- The dtor does not handle an exception that happend to be
>|> >  be raised - unexpected() is called.
>
>|> Yes, and what if the programmer has defined unexpected()
>|> to rethrow the exception?  (In most circumstances, doing so
>|> is probably a much better idea than just crashing via
>|> a call to abort().)
>
>1. How can it know what the exception was to rethrow it?  Is a throw
>without an argument legal here?  (I don't think so, but I'm not sure.)

Yes, a `throw;' statement is legal within an unexpected() handler.
15.1/5-6 is quite clear:

| 5 A  throw-expression  with no operand rethrows the exception being han-
|   dled without copying it.  
| 
| 6 The exception thrown is the one most recently caught and not finished.
|   An  exception is considered caught when initialization is complete for
|   the formal parameter of the corresponding catch clause, or when termi-
|   nate()  or  unexpected()  is  entered due to a throw.  An exception is
|   considered finished when the corresponding catch clause exits.

On entering unexpected(), the exception is considered handled, but not
finished, so `throw;' is fine.

The ARM contains an example of the use of `throw;' in an unexpected
handler (pages 365-366).

>2. This behavior doesn't seem conform to the required behavior in
>18.6.1.2.  I believe that when a user provided routine violates required
>behavior, undefined behavior results.

Hmm, you're right - according to 18.6.1.2, an unexpected handler
must not throw the same exception.  This would seem to imply that
`throw;' would be ok in an unexpected handler only if the exception didn't
escape, e.g.

	void my_unexpected_handler() { try { throw; } catch(...) {} }

and also that the example in the ARM has undefined behaviour.
On the other hand, 15.5.2 definitely seems to assume that an
unexpected handler can throw an exception not in the exception
specification, and carefully describes the behaviour in that case.

So the draft is self-contradictory here.  I think all you can really
say is that one of 15.5.2 and 18.6.1.2 is wrong.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
I will have little or no net access from Nov 30 until Dec 25.
Please email me a copy of any follow-ups.

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