From 7451067070267325032 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-18 09:17:58 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!colt.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, 18 Sep 2002 16:17:57 +0000 (UTC) Organization: ntl Cablemodem News Service Lines: 111 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <6df0c6a8.0208260746.633710cb@posting.google.com> <6df0c6a8.0209051026.5df687db@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> X-Trace: mail2news.demon.co.uk 1032365877 6522 10.0.0.1 (18 Sep 2002 16:17:57 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 18 Sep 2002 16:17:57 +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 17rhWV-0001h3-00 for mail2news@news.news.demon.net; Wed, 18 Sep 2002 16:17:56 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id CAA00399; Thu, 19 Sep 2002 02:17:49 +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, 18 Sep 2002 14:10:09 BST Xref: archiver1.google.com comp.std.c++:14010 Pierre Baillargeon: > Frankly, I'm starting to find this thread pointless. Well, if we're *boring* you, don't post anymore ;-) But if you keep posting, people are going to keep replying, if only to correct mistakes and misunderstandings. > All replies go > along the same lines: it's dangerous to throw from destructors, so > don't do anything in destructors. No, what I and others are actually saying is "it's (generally) dangerous to throw from destructors, so (generally) don't throw from destructors". (I use the weasel word "generally" because there are some cases where throwing from destructors is not dangerous, but as far as I can tell your code isn't one of these cases. This is the same weasel word the standard uses for the same advice, so at least I'm in good company ;-) > No one considers the alternative: if > it were not dangerous to throw from destructors we could do useful > things in destructors. We can already do useful things from destructors. We just can't (generally) throw. 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. > 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. > They all fail to address the usability problems. > The usability problems are: > > - Having to put code in a separate function/object/class. > - Not having access to local variables. > - Spreading the code in many places, making it harder to > read/understand. > - One-use code forced to be put in a reusable function/object/class. > - Harder to nest multiple levels of arbitrary headers/footers. 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. > 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: "The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression is called 'stack unwinding.' [Note: If a destructor called during stack unwinding exits with an exception, terminate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor. -end note]" > but it > can be avoided *easily* with a single if. std::uncaught_exception *again*? > 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). 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". 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 ]