From -161793946124832169 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-22 22:19:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: belvis@pacbell.net (Bob Bell) Newsgroups: comp.std.c++ Subject: Re: Proposal: exception stack unwinding resumption Date: Mon, 23 Sep 2002 05:19:23 +0000 (UTC) Organization: http://groups.google.com/ Lines: 64 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: 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> <6df0c6a8.0209201925.6faa9e57@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1032758364 23805 10.0.0.1 (23 Sep 2002 05:19:24 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 23 Sep 2002 05:19:24 +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 17tLcw-0006Bn-00 for mail2news@news.news.demon.net; Mon, 23 Sep 2002 05:19:22 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id PAA28348; Mon, 23 Sep 2002 15:19:18 +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: 22 Sep 2002 17:39:19 GMT Xref: archiver1.google.com comp.std.c++:14114 pierrebai@hotmail.com (Pierre Baillargeon) wrote in message news:<6df0c6a8.0209201925.6faa9e57@posting.google.com>... > 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. I would think that is appropriate. Any discussion of a change to the standard should involve a discussion of current best practice, in order to establish that, in some way, current best practice is not good enough. This has not yet been established, so there is crucial support missing from your proposal. Your proposal seems to change what is currently a simple, easy to understand, easy to follow rule into something complex and error prone. I don't see the improvement. You propose allowing an unhandled exception to be discarded and replaced by an exception thrown in a destructor. This seems like a really bad idea, because you're saying that under some circumstances it's OK to throw away information. If a low-level function throws an exception that should go to a high-level caller, an exception in a destructor would "short-circuit" that. In fact, it seems that an exception could trigger a cascade of destructor exceptions: in some low-level function a std::bad_alloc is thrown. During unwinding, an A object's destructor throws an X. During unwinding for that, a B throws a Y. At this point, three exceptions have been thrown, only the last one of which will actually get to a catch handler. Not only will the caller not know about (and be able to respond to if it wants) the allocation failure, it will not know that the A destruction failed. This cascade can go on indefinately, so how many failures will be unreported? Also, when the new exception replaces the old one, presumably the old exception will be destroyed. What happens if that destruction throws an exception? I suppose that the answer depends on when that destruction takes place, and it may seem like an obscure case, but this is your proposal, and it should go all the way down. What happens? Finally, you haven't simplified the implementation of destructors, you've complicated it. Because now they may have to be sensitive to whether or not throwing is "allowed." If not (if some higher-level caller hasn't called set_unwinding_resumption(true)), the destructor must absorb the exception and prevent its escape. So under some circumstances this destructor reports errors, and under others it doesn't? I don't know about you, but this would simply encourage me to take the simpler road: destructors never throw. Bob --- [ 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 ]