🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2752

Re: Exceptions in destructors

#2752
From: Fergus Henderson
Date: Tue, 28 Nov 1995 17:26
50 lines
2747 bytes

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

>Herb Sutter (herbs@interlog.com) wrote:
>|> In article <494oog$hmf@gabi.gabi-soft.fr>,
>|>    kanze@gabi-soft.fr (J. Kanze) wrote:
>|> >2. This behavior doesn't seem conform to the required behavior in
>|> >18.6.1.2. 

Although I originally agreed with your interpretation, I now disagree.
The behaviour (throwing an exception that does not satisfy the
exception specification) does not violate any requirement.

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

I think it is just confusing prose.  I don't think the draft disallows it.
The use of "may" with a list of options does not imply that the list
is exhaustive.

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

Right.  And as 15.5.2/3 says, this guarantee holds.  But the reason is
*not* because an unexpected handler isn't allowed to throw an
unexpected expection -- it is. 

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

No, neither of those cases holds.  The reason that the guarnatee holds
is that if an unexpected handler does throw an unexpected exception,
the unexpected() function which called the handler will replace that
exception with a `bad_exception' exception.

--
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. ]
Technical Details
Message-ID: <9533212.28401@mulga.cs.mu.OZ.AU>
Path: arc1-ca.pugleaf.net!128.32.155.1!matt
References: <Pine.SGI.3.91-heb-2.02.951114164854.2393A-100000@arava> <48s8fa$aq@sunsystem5.informatik.tu-muenchen.de> <9532523.1824@mulga.cs.mu.OZ.AU> <494oog$hmf@gabi.gabi-soft.fr> <495ls8$17o@steel.interlog.com> <49bvoc$o30@gabi.gabi-soft.fr>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!128.32.155.1!matt
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.std.c++
Subject: Re: Exceptions in destructors
Date: 28 Nov 1995 17:26:20 GMT
Organization: Computer Science, University of Melbourne, Australia
Approved: matt@physics2.Berkeley.EDU (Matt Austern)
Message-ID: <9533212.28401@mulga.cs.mu.OZ.AU>
References: <Pine.SGI.3.91-heb-2.02.951114164854.2393A-100000@arava> <48s8fa$aq@sunsystem5.informatik.tu-muenchen.de> <9532523.1824@mulga.cs.mu.OZ.AU> <494oog$hmf@gabi.gabi-soft.fr> <495ls8$17o@steel.interlog.com> <49bvoc$o30@gabi.gabi-soft.fr>
NNTP-Posting-Host: physics2.berkeley.edu