From -8011106164686791439 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-04 11:00:19 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: glancaster@ntlworld.com ("Garry Lancaster") Newsgroups: comp.std.c++ Subject: Re: Proposal: exception stack unwinding resumption Date: Wed, 4 Sep 2002 18:00:18 +0000 (UTC) Organization: ntlworld News Service Lines: 104 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <6df0c6a8.0208260746.633710cb@posting.google.com> <6df0c6a8.0209030656.249192ce@posting.google.com> X-Trace: mail2news.demon.co.uk 1031162418 12672 10.0.0.1 (4 Sep 2002 18:00:18 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 4 Sep 2002 18:00:18 +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 17meRs-0003IF-00 for mail2news@news.news.demon.net; Wed, 04 Sep 2002 18:00:16 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id EAA04403; Thu, 5 Sep 2002 04:00:13 +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-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-NNTP-Posting-Date: Wed, 04 Sep 2002 10:50:17 BST Xref: archiver1.google.com comp.std.c++:13592 Garry Lancaster: > > (However, item 19 in Herb Sutter's "More Exceptional > > C++" explains why this can sometimes generate false > > positives. If you don't have the book the problem is > > shown by: > > > > bar::~bar() { > > try { > > foo f; > > // whatever. > > } catch(...) { > > // whatever. > > if( !std::uncaught_exception() ) throw; > > } > > } > > > > If a bar is destroyed during stack unwinding, f's > > destructor will never throw, even though it is safe > > to do so.) > > > > I don't think the proposal adds enough to what we > > already have to warrant its inclusion in the language. Pierre Baillargeon: > Doesn't your example shows that the situation is not simple? I know > the solution is to compare the situation as seen in the constructor > with the one in the destructor, but it involves a burden on all > classes. Each data member also has to keep it own private value. That won't work e.g. bar::~bar() { foo f; } As before, a bar is destroyed during stack unwinding but in this case it is *not* safe for f's destructor to throw. 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. > 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." > 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. 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. 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. [snip] Kind regards Garry Lancaster Codemill Ltd Visit our web site at http://www.codemill.net --- [ 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 ]