🚀 go-pugleaf

Herb Sutter (herbs@interlog.com) wrote:
|> In article <494oog$hmf@gabi.gabi-soft.fr>,
|>    kanze@gabi-soft.fr (J. Kanze) wrote:
|> >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?

|> I think he wants unexpected() to be called, rather than an inelegant 
|> terminate(), when a dtor throws during unwinding.

|> >|> >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.)
|> 	
|> I was about to say that it must be legal -- this is precisely what Cline
|> and Lomow suggest in their FAQ book (FAQ #271).  However:

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

|> [Note: 18.6.1.2 in the April draft is now 18.6.2.2 in the Sept WP.]

|> It seems you're right, since the unexpected_handler isn't supposed to throw
|> the same (unexpected) exception again.  Relevant section follows (from the
|> Sept WP; the April draft looks identical):

|> ---8<---8<----------------------------------------------------------------
|>   Required behavior:
|>     an  unexpected_handler  shall either throw an exception or terminate
|>     execution of the program without returning to the caller.  An  unex-
|>     pected_handler may perform any of the following:

|>   --throw an exception that satisfies the exception specification;
|>   --throw a bad_exception exception;
|>   --call terminate();
|>   --call either abort() or exit();

|>   Default behavior:
|>     The implementation's default unexpected_handler calls terminate().
|> ---8<---8<----------------------------------------------------------------

|> Is disallowing a rethrow deliberate, or something that could be relaxed to 
|> allow rethrowing as Cline and Lomow suggest?

I would imagine that it must be deliberate.  The whole purpose of
exception specifications is to offer some sort of a run-time guarantee
as to which exceptions may propagate out.  Unexpected is called because
the program is attempting to violate that guarantee; if unexpected
re-throws the same exception, either it causes unexpected to be called
again (resulting in an endless loop), or the guarantee is violated (and
thus not a guarantee).
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ 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. ]