From -1970882664725436983 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,96a8c01f7043c2d9 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-23 09:20:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: pierrebai@hotmail.com (Pierre Baillargeon) Newsgroups: comp.std.c++ Subject: Re: Proposal: exception stack unwinding resumption Date: Mon, 23 Sep 2002 16:20:45 +0000 (UTC) Organization: http://groups.google.com/ Lines: 125 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <6df0c6a8.0209230602.2aba3ca8@posting.google.com> References: <6df0c6a8.0208260746.633710cb@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 1032798045 29212 10.0.0.1 (23 Sep 2002 16:20:45 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 23 Sep 2002 16:20:45 +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 17tVwo-0007b1-00 for mail2news@news.news.demon.net; Mon, 23 Sep 2002 16:20:35 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id CAA06208; Tue, 24 Sep 2002 02:20:26 +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: 23 Sep 2002 14:02:06 GMT X-MailScanner: PASSED (v1.2.6 34897 g8NE2BKf043462 mailbox2.ucsd.edu) Xref: archiver1.google.com comp.std.c++:14134 belvis@pacbell.net (Bob Bell) wrote in message news:... > pierrebai@hotmail.com (Pierre Baillargeon) wrote in message news:<6df0c6a8.0209201925.6faa9e57@posting.google.com>... > > > > 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. Where I disagree with your point is that my proposal *changes* what would be considered best practice. And in fact I do illustrate where the current best practice fails: - In automating things that can fail. - In the difficulty of writing and testing that no destructor can ever throw. > 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. Where is the complexity? The current rule is easy to understand, easy to get wrong. Tell me: how do you actually test that no exception will ever be thrown from a destructor? The new rule is easy to understand: you can throw from a destructor. Where is the complexity? > You propose allowing an unhandled exception to be discarded and > replaced by an exception thrown in a destructor. This is incorrect. What I'm proposing is that the second exception is ignored. It is like putting a try block around all destructors when stack unwinding is under way. Which is *what you currently need to do*! > 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. Tell me, what do you do in your destructors to have them not throw? You put a try/catch. You catch everything, including divisions by zero and invalid memory accesses on some implementation (MSVC++). You loose information. That is the current best practice. My proposal just makes it automatic, language-enforced. You gain flexibility in the bargain because in the normal case (i.e.: not stack unwinding), your destructors will *not loose information*. So acording to you, my proposal is a gain. right? ;-) > 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. No more than what it already going on. If your destructor needs an A and a B, what are you doing now? Using a try block and swallowing the exception, or terminate(). > 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? The first part your affirmation is wrong, as I've pointed out before. The second, also, since current best practice is to ignore additional exceptions anyway. > 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? The first part is false, so the second doesn't hold. As for successive ignored exceptions, before being thrown they are an automatic object and will be destroyed like other automatic objects. A real problem, that I've actually seen in many libraries and systems, is exception classes that contains a std::string or MFC CString. Which may allocate memory when copied during the exception throw process. And sometimes, they are even catched by value! My proposal won't solve these errors, BTW, since it concerns only things done during destruction of stack objects, not the reception of the exception objects. > 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. While this problem is true in theory, it won't be in practice, IMO. The first case, when it is set to true is no problem: old classes will go on using try blocks, and new ones will be happy. The second case. when it is set to false. The question is when will it be set to false? Not by old classes, since they are not aware of the existence of the function. So it will probably be managed by a singleton that keeps a ref-count counter to know when to set it back to false. The common case, I expect, will actually be that it is either never used or set to true once and for all in main() and in all statically created singletons that are constructed before main(). -- Pierre B. --- [ 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 ]