🚀 go-pugleaf

herbs@interlog.com (Herb Sutter) writes:

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

Why is calling unexpected() more elegant than calling terminate()?
By default, they will both do the same thing - call abort().

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

It definitely *was* legal not so long ago.

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

The committee made a decision that exception specifications should be
fully enforced, in the sense that a function should never be allowed to
throw an exception not in its exception specification.  This was a
change from the ARM, which allowed an unexpected handler to throw any
exception, and passed such exceptions up unchanged.  But, rather than
force the program to always abort if a function throws an incorrect
exception, `bad_exception' was allowed as an escape hatch.  The
committee decided that if an unexpected handler threw an unexpected
exception, and `bad_exception' was part of the function's exception
specification, then the thrown exception would get replaced with
bad_expection.  This is reflected in the text of 15.5.2.

|   15.5.2  The unexpected() function                  [except.unexpected]
| 
| 2 The unexpected() function shall not return, but it can throw  (or  re-
|   throw) an exception.  If it throws a new exception which is allowed by
|   the exception specification which previously was  violated,  then  the
|   search  for  another handler will continue at the call of the function
|   whose exception specification was violated. If it throws or  rethrows
|   an  exception that the exception-specification does not
|   allow then the following happens: if the exception-specification  does
|   not  include  the  name of the predefined exception bad_exception then
|   the function terminate() is called, otherwise the thrown exception  is
|   replaced by an implementation-defined object of the type bad_exception
|   and the search for another handler will continue at the  call  of  the
|   function whose exception-specification was violated.
| 
| 3 Thus,  an  exception-specification  guarantees  that  only  the listed
|   exceptions will be thrown.  If  the  exception-specification  includes
|   the  name  bad_exception  then  any  exception  not on the list may be
|   replaced by bad_exception within the function unexpected().

However, as far as I can tell, there was some confusion as to where
unexpected exceptions would get replaced by bad_exception, because
the text in 18.6.2.1 [lib.unexpected.handler] seems to supplant this,
making everything but the first two sentences in the above quoted
text useless, because it implies that if an unexpected handler throws
or rethrows an exception that the exception-specification does not allow,
then the behaviour is undefined.

Ah!  I think I understand now.  18.6.2.1 says than an unexpected
handler "may" do various things, which do not include throwing an
exception that the exception-specification does not allow.  But it does
*not* say that it may not do anything else.

|   18.6.1.2  Type unexpected_handler             [lib.unexpected.handler]
| 
|   typedef void (*unexpected_handler)();
| 
| 1 The  type  of  a  handler function to be called by unexpected() when a
|   function attempts to throw an exception not listed in  its  exception-
|   specification.
|   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();

Note the difference between "shall" and "may" here.
I think the second sentence is effectively non-normative.

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