From 8270448773407374174 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-05 11:41:09 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed1.bredband.com!bredband!diablo.netcom.net.uk!netcom.net.uk!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: pierrebai@hotmail.com (Pierre Baillargeon) Newsgroups: comp.std.c++ Subject: Re: Proposal: exception stack unwinding resumption Date: Thu, 5 Sep 2002 18:41:07 +0000 (UTC) Organization: http://groups.google.com/ Lines: 103 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <6df0c6a8.0209051026.5df687db@posting.google.com> References: <6df0c6a8.0208260746.633710cb@posting.google.com> <6df0c6a8.0209030656.249192ce@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1031251267 23530 10.0.0.1 (5 Sep 2002 18:41:07 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 5 Sep 2002 18:41:07 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 17n1Yw-00067N-00 for mail2news@news.news.demon.net; Thu, 05 Sep 2002 18:41:06 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id EAA22101; Fri, 6 Sep 2002 04:40:31 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: 5 Sep 2002 18:26:38 GMT Xref: archiver1.google.com comp.std.c++:13643 glancaster@ntlworld.com ("Garry Lancaster") wrote in message news:... > > Without knowledge of its call context over and above > whether stack unwinding is occurring (even if it > knows whether it was occurring during object > construction), the foo destructor cannot know > whether it is safe to throw. Any solution that > seeks to make the throwing of exceptions from > destructors context-dependent needs to address > this point. I agree with your point but disagree with your analysis. The fact that a destructor throws must be documented and using objects that have a throwing destructor implies (currently) responsabilities on the programmer to use it correctly. All this supports the need for an easier solution! > > > There > > is also the problem of classes that I do not write, like standard > > containers, althought I haven't encoutered problems so far in real > > life. > > See 17.4.4.8/3: > > "No destructor operation defined in the C++ Standard > Library will throw an exception." Since they are templated, they only asserts this for their own code. There may be a requirement that destructors of contained objects not throw. I only used them as an example, as I've never had any problem. > > > The solution I proposed is just like yours, except it involves no > > user-written code. > > Your previous explanation of set_unwinding_resumption > mentioned setting flags in destructors. The > std::uncaught_exception approach also is invasive of > the destructor. So there is no difference in terms of > whose code must be changed. You are right, because my original post was trying to be conservative in its usage of set_unwinding_resumption(). In reality, I rather think that I would set the flag as the first thing in main() and design all classes accordingly. That is what I'm doing now, except that I have to salt all my code with exception filtering. > Good general advice is to do as the standard library > does and not to throw from a destructor. Clean-up > which really can fail is done in a non-destructor > function. I'd agree if RAII had not made me so much more productive. I could write a long rant detailing my experience, but I'll simply say this: these posts made me reflect on my usage of RAII and I realized that for an entire year I completely forgot that there could be bugs in the base layer of my design because it has been so flawless, thanks to RAII. Unfortunately, it means my destructors can throw. > If we absolutely must do the might-throw > cleanup in a destructor we have two reasonable > choices if an exception is thrown: > > (a) If the program can survive the failure and > continue to work correctly. Swallow the exception > inside the destructor, maybe emit some kind of > run-time diagnostic then continue normal exectution. > > (b) If the program cannot survive the failure. > Terminate. > > The third choice - to make the behaviour of the > destructor dependent on its context - is in my > experience very rarely required, if ever. As such, > providing the language with another system for > doing it, over and above what we already have, > seems to me a low priority. If your experience is > different, perhaps you could show one or two > motivating examples. This is were the biggest disagreement lies, IMO. The only context is weither stack-unwinding is under way and as such that there is already a problem being reported. The idea is to allow error-reporting from destructor unless there is already an error in the midst of being reported. IOW, both (a) and (b) are wrong. Swallowing all errors even when they could have been reported is wrong. Letting the program terminate just because a second error occured while a first error is in flight to the higher-level logic in charge of error handling is wrong. All non-exception based error handling I've used always return a single error. They either return the earliest or latest error. Some more intelligent error handling systems will log the unreported error. That is what I want when using exceptions. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]