Article View: comp.std.c++
Article #2752Re: Exceptions in destructors
From: Fergus Henderson
Date: Tue, 28 Nov 1995 17:26
Date: Tue, 28 Nov 1995 17:26
50 lines
2747 bytes
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!mattReferences:
<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