From -871195271022458151 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-16 12:14:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!212.74.64.35!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: Allan_W@my-dejanews.com (Allan W) Newsgroups: comp.std.c++ Subject: Re: Proposal: exception stack unwinding resumption Date: Mon, 16 Sep 2002 19:14:01 +0000 (UTC) Organization: http://groups.google.com/ Lines: 69 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <23b84d65.0209161107.23bea618@posting.google.com> 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> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1032203641 16826 10.0.0.1 (16 Sep 2002 19:14:01 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 16 Sep 2002 19:14:01 +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 17r1Jo-0004NF-00 for mail2news@news.news.demon.net; Mon, 16 Sep 2002 19:14:00 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA20424; Tue, 17 Sep 2002 05:13:25 +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: 16 Sep 2002 19:07:45 GMT Xref: archiver1.google.com comp.std.c++:13942 > 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. > glancaster@ntlworld.com ("Garry Lancaster") wrote > ;-) > > 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? So you're suggestion would be to make the code snippet above become good style? For the reasons that you first mentioned, using the destructor of object DocumentSection to write the report footer would be a bad idea. The obvious refactoring is also probably the best: void foo() { // Ctor initializes, but does not write anything to report DocumentSection d; d.write_header(); // Writes header write_body(); // Throws! d.write_footer(); // Writes footer // Dtor cleans up resources, but does not write to report } > > 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. Exactly, which is why RAII-style footers are a bad idea. Because a tool can be abused, doesn't make it a bad tool -- in fact, any tool can be abused. (Do you know how dangerous a for()-loop is? How about the "break" statement?) A footer is not a "Resource." The RAII (Resource Aquisition Is Initialization) coding technique is not an appropriate way to generate it. --- [ 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 ]