From -7235075507238900520 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-21 12:08:08 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: pierrebai@hotmail.com (Pierre Baillargeon) Newsgroups: comp.std.c++ Subject: Re: Proposal: exception stack unwinding resumption Date: Sat, 21 Sep 2002 19:08:08 +0000 (UTC) Organization: http://groups.google.com/ Lines: 117 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <6df0c6a8.0209201925.6faa9e57@posting.google.com> References: <6df0c6a8.0208260746.633710cb@posting.google.com> <6df0c6a8.0209100534.619b8531@posting.google.com> <6df0c6a8.0209121133.6f081c37@posting.google.com> <23b84d65.0209161107.23bea618@posting.google.com> <6df0c6a8.0209170602.2cb54634@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1032635288 8713 10.0.0.1 (21 Sep 2002 19:08:08 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 21 Sep 2002 19:08:08 +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 17spbq-0002GO-00 for mail2news@news.news.demon.net; Sat, 21 Sep 2002 19:08:06 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA04977; Sun, 22 Sep 2002 05:08:03 +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: 21 Sep 2002 03:25:31 GMT X-MailScanner: PASSED (v1.2.6 37159 g8L3PViQ039573 mailbox3.ucsd.edu) Xref: archiver1.google.com comp.std.c++:14094 glancaster@ntlworld.com ("Garry Lancaster") wrote in message news:... > Pierre Baillargeon: > > No, what I and others are actually saying is "it's > (generally) dangerous to throw from destructors, so > (generally) don't throw from destructors". And what I'm saying is "what if we allowed it to be non-dangerous if desired". The original thread was about a change to the standard, not a discussion of current best practice. > We don't need to change the language to get > your code to do the right thing in the face of > exceptions (which is probably why we have > moved away from discussing your proposed > language change). We just need to change > your code. My proposal is not about making my code do the right thing: it already does. But my code sometimes blocks exceptions when it would have been possible to throw, because I don't want to keep an exception-state variable in all my classes. The proposal is about: - Simplifying that situation. - Removing an obscure bug that abrutly ends a program, that I claim most C++ programmers don't even know exists and which is easy to get wrong by a single possibly-throwing call in a destructor. - Allowing error reporting from a destructor using exception, since the fear of termination no longer exists. - Which in turn allow more things, which need to be done/undone, to be automated using RAII-like classes. > > All suggestions always have to do with putting the header/footer pair > > in a function with the body either a virtual function or templated. > > Not true. See Allan W.'s more straightforward > refactoring in the message you are replying to. > It doesn't do the function bracketing you are > after, but it does work. When I showed the skeleton of my code design, at your request, it was to illustrate the usage of a RAII-like class that can throw in a destructor, to show why I wanted to be able to throw from a destructor safely. It was also to part of my claim that those RAII-like classes *because of their automation* saved me a lot of headache. Removing the automation solves the exception-from-destructor problem by simply bringing back the orginal problem of having to call footers manually. > > They all fail to address the usability problems. > > As already discussed, functional decomposition, > which is the umbrella term for most of your gripes > when stripped of editorialising, is generally a > good thing. But of course can be overdone. Is this an agreement to my points? Or just, when striped of editorialising, pontification? > > Some claim that the destructor will somehow corrupt the data, > > The "claim" is simply that if a destructor throws, > when the destructor was itself called by the > exception handling stack unwinding mechanism, > the program will terminate. Maybe you doubt this, > but the standard is quite clear. 15.2/3 reads: Umph. Isn't this exactly what I wrote in my orignal post and the exact reason why I called for a change? IOW, once again you seem to be agreeing with me now. > > but it > > can be avoided *easily* with a single if. > > std::uncaught_exception *again*? So you agree with me that a change is needed, right ;). Seriously, I don't follow your point: If I really want to avoid doing the footer when the body failed, how does that generate an std::uncaught_exception? > > I don't only because I don't > > need that capability. > > This is burying your head in the sand. > You may have reservations about the alternatives > offered so far, but at least they all work. At the > moment your code doesn't work, at least when > you consider its behaviour in the face of > exceptions (which you almost certainly should). I already told you in my september 5th post that my code use exception filtering. IOW, I already do check before letting exceptions escape my destructors, but I have to write that check in all destructors. And as I said, that means that some destructors that could have thrown (because they really were inside another try block) don't, because (as I already said in this post in in earlier ones, sigh) I would have to keep a flag in all instances of all classes. > The simple rule is: start with something that > works, then improve it. > > Another simple rule: before you can solve a > problem you have to admit that you have one. > Until you do this, you will probably continue to > find the thread "pointless". I am not allowed to reply to this by the comp.std.c++ chart. --- [ 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 ]