From -896872839129962239 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-11 11:32:36 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, 11 Sep 2002 18:32:36 +0000 (UTC) Organization: ntlworld News Service Lines: 107 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> <6df0c6a8.0209051026.5df687db@posting.google.com> <6df0c6a8.0209100534.619b8531@posting.google.com> X-Trace: mail2news.demon.co.uk 1031769156 24260 10.0.0.1 (11 Sep 2002 18:32:36 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 11 Sep 2002 18:32:36 +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 17pCHy-0006J9-00 for mail2news@news.news.demon.net; Wed, 11 Sep 2002 18:32:34 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id EAA10613; Thu, 12 Sep 2002 04:32: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-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, 11 Sep 2002 14:04:51 BST X-MailScanner: PASSED (v1.2.6 28405 g8BD4sfu032975 mailbox4.ucsd.edu) Xref: archiver1.google.com comp.std.c++:13826 > > Pierre Baillargeon: > > > 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. Garry Lancaster: > > Aha. This is the root of all the confusion, I think. RAII > > does not mean destructors must be able to throw. > > > > If you are using your throwing destructors with the > > standard libary or any other template library you > > really need to address this misconception. See > > for example this part of the C++ standard: Pierre Baillargeon: > I am not, so the point is not relevant. I still think any misconception worth squashing. > To give you an idea of the > kind of work I do using RAII, I use it to output the structure of a > PDF file. The PDF specification requires a lot of meta information to > be kept around and output later, and all data is embedded in objects > with different layers of embedding, compression and encoding. Without > RAII, the user must remember when to call each little function. > Everything has a header and footer, most of the time multi-levels. It > is easy to get wrong and the PDF tools are not friendly as far as > error reporting goes. RAII stands for "resource allocation is initialization". This is still rather opaque. Actually, it is the technique of using a destructor to release resources allocated in a constructor. Using destructors to create document footers or add other document formatting is rather stretching the definition of "resource". Using destructors for other things is not necessarily wrong, but it isn't RAII. (For example, simple sentry classes can be very useful.) Having said that, destructors that throw are often problematic. If we have a class that formats a document header in its constructor and formats a document footer in its destructor, where the latter may throw, will it really do what we want should an exception be thrown after the object's construction and prior to destruction? void foo() { DocumentSection d; // ctor does header, dtor footer. write_body(); // throws! } Even if the destructor succeeds, the footer will likely appear in the wrong place since the whole of the body may not have been written before the exception was thrown. If the destructor fails, the program will, by default, terminate. Mucking around with uncaught_exception or similar may change the exact behaviour, but it will still be a hard-to-understand mess. There are other ways to automatically bracket a pre- and post- operation that don't suffer from these issues. For example, the Template Method pattern from Gamma et al.'s "Design Patterns", which can be implemented using virtual functions (as in the book) or C++ templates (shown below). void foo() { DocumentSection d; // Ctor and dtor now simple. d( write_body ); } template void DocumentSection::operator()(BodyWriter f) { write_header(); f(); write_footer(); } > I can't possibly show you proprietary code. And we don't want to see it either! Just create an example that demonstrates the issue and is as short and simple as possible. At the moment you're forcing us to guess exactly what your real problem is. [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 ]