From 1404916614180852766 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-13 13:10:18 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: Fri, 13 Sep 2002 20:10:18 +0000 (UTC) Organization: ntl Cablemodem News Service Lines: 173 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> <6df0c6a8.0209121133.6f081c37@posting.google.com> X-Trace: mail2news.demon.co.uk 1031947818 17118 10.0.0.1 (13 Sep 2002 20:10:18 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 13 Sep 2002 20:10: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 17pwlc-0004Rx-00 for mail2news@news.news.demon.net; Fri, 13 Sep 2002 20:10:16 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id GAA02583; Sat, 14 Sep 2002 06:10:11 +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: Fri, 13 Sep 2002 11:29:30 BST Xref: archiver1.google.com comp.std.c++:13886 Garry Lancaster: > > 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. Pierre Baillargeon: > In the particular example you give, the footer will be at the right > place, but the body content will be bad. ;-) That's another way of looking at the same behaviour. Put it this way: if the exception occurs before the body is fully written, the footer will appear before the end of the body. (The end of the body will not be written at all.) Agreed? > But the current design is > that the PDF document must be all valid: an error output in a single > object makes the document invalid and it gets deleted. Seems reasonable, although I still think it would be more intuitive for all document output to stop as soon as the first error is encountered. The main problem is still, as we know, how to deal with destructors that throw. [snip] > > 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(); > > } > > > Yes, I know of this pattern and it actually used in the RAII classes > to write the header and footer! As I explained before, unless the destructor is releasing a resource, it isn't using RAII. Writing a footer is not releasing a resource. A destructor whose only action is to write a footer is not using RAII. RAII does not mean "putting code into destructors". It's more specific than that. > The basic design is: > > struct Writable > { > virtual void begin_write(...) = 0; > virtual void write(...) = 0; > virtual void end_write(...) = 0; > }; > > struct Writer > { > Writer( Writable & aWr ) : wr ( aWr ) > { > wr.begin_write(); > } > > ~Writer() > { > wr.end_write(); > } > }; > > The problem with the your implementation is that the body, f() in your > code, has to be written in a derived classes. Not true. f is either a pointer to a free function or a function object ("functor"). It's the same technique used by many of the standard s e.g. std::for_each. > This disperses the code, making it unreadable. It "encourages" functional decomposition. Which, like most good things, can be overdone. Now you've supplied an example we can see this could be an issue in this case. > It also requires writing a function for every usage, > making it hard to use. Since it's a template, this isn't true. We supply a function template and the *compiler* writes the correct function for each instantiation. > Also consider the requirement that > multiple levels of imbrication must be supported. What do you mean by "imbrication"? (I'm not being pedantic about a typo or spelling - I really don't know what you mean.) > Here's a typical > fictional example (include and namespace omited): > > int main() > { > PDF pdf("hello.pdf"); > Page page(pdf); > Stream content(pdf); > page[Name::Contents] = Ref(content); > FlateEncoder flate(content); > ASCII85Encoder a85(flate) > Writer writer1(a85); > writer << "(Hello World!) Tj\n"; > Writer writer2(page); // Dtors are now called in the following order: // writer2 // writer1 // a85 // flate // content // page // pdf // Is that the intended order? > } Good. Examples make things so much easier to explain. Can you: (a) Indicate which of these objects has a destructor that can throw (these are the ones that need attention); and (b) Show the body of one of these destructors (so we can see what the current behaviour is in the face of exceptions) ? 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 ]