🚀 go-pugleaf

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

>Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
>|> The ARM contains an example of the use of `throw;' in an unexpected
>|> handler (pages 365-366).
>
>Great.  So what does it mean.  Suppose I write a function:
>
>	void f() throw() ...
>
>What I'm trying to guarantee is that this function does not throw any
>exceptions; this is a very important guarantee if exception safety is to
>be taken seriously.  In fact, of course, I've only guaranteed that it
>won't throw any exceptions other than bad_exception (which is already a
>serious compromise).

The guarantee didn't hold in ARM C++, but it *does* hold in DWP C++.
If you haven't explicitly listed bad_exception in the exception specification,
then an unexpected exception will result in a call to terminate() if
the unexpected handler rethrows the exception.

>(IMHO, at least in the case of throw(), even bad_exception shouldn't
>propagate out. Basically, allowing bad_exception to be an exception
>means that even functions like the above can throw exceptions, which in
>turn makes exception safety significantly harder; you must be prepared
>to accept an exception at any time, since there is *no* way to ensure
>that a given function never throws an exception.)

The committee agreed with you - bad_exception can't propagate out
unless explicitly listed.  However, I still don't really agree with
your point about it making exception safety easier.
That depends on how you define exception safety.  If you define
exception safety to mean "no resource leaks in the presence of exceptions",
then yes, you are right.  But this simplistic version is not a good definition.
A better definition would be "no resource leaks or calls to abort()
in the presence of exceptions" - after all, a call to abort() is worse
than a resource leak, right?  If you adopt this definition, then
exception safety is very difficult.  A more realistic definition 
of "reasonable exception safety" (rather than "perfect exception safety")
might be "no calls to abort(), and no resource leaks except in the
case of a bad_exception".  This is safer than the simplistic
version, but still doesn't require you to worry about resource
leaks in the difficult cases.  In other words, using
`foo() throw(bad_exception)' rather than `foo() throw()'
can result in better safety without any additional difficulty.

That's the theory, anyway.  I've heard it said that many people
with real experience in using exception handling in large projects
don't agree, but I have not heard *why* they don't agree.

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

I've changed my interpretation since I wrote that.  I now think that
we all just misread 18.6.1.2, taking it to imply more than it really said.

>I don't really think that this is a contradiction.  15.5 is speaking
>about when the C++ language considers an exception finished (and thus,
>*potentially* capable of being rethrown). 

Um, I'm confused.  Are you reading a different 15.5 to me?
My 15.5 [special functions] is about unexpected() and terminate().

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