From -4230830418241384867 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,54d225d76071a8d,start X-Google-Attributes: gidf78e5,public From: dak Subject: Re: Exceptions in ctors/dtors? Date: 1996/09/09 Message-ID: #1/1 X-Deja-AN: 179495547 x-original-date: Mon, 9 Sep 1996 10:16:19 -0400 (EDT) organization: - x-auth: PGPMoose V1.1 PGP comp.std.c++ newsgroups: comp.std.c++ originator: austern@isolde.mti.sgi.com Steve Clamage (clamage@taumet.Eng.Sun.COM) wrote: > In article e2i@netlab.cs.rpi.edu, Max Polk writes: > > Perhaps it is a bad idea ONLY because a bad rule exists that > >terminate() will be called immediately. > > It's easy to call it a bad rule without suggesting an alternative. > What do you suggest? > > Whatever you suggest as a replacement rule should be more usable and > have generally better results than just calling terminate(). Here are > a few things to consider. > > Suppose while unwinding the stack to handle exception 1, a > destructor exits via exception 2. What should happen? What about handling whichever exception handler is first encountered. At first sight it might seem inappropriate but: - In the previous error handling scheme (either return value or static error record) that is what happened. The first block of code which handled any error was first executed, whatever the order of error. - There is not real hard reason why an error should be handled first just because it happened first. In fact, executing whichever handler comes first actually makes sense since the programmer chose in which order to handle the exceptions. - Innermost handler are ussually there to protect the rest of the world about a specific exception. Passing over it because its exception didn't come first might not be appropriate. Some very important code might be skipped. [...] > Executing some > other handler in the middle of deciding what to do about the first > exception doesn't seem the the obviously correct thing to do. But > if we just keep unwinding the stack, the effect is to ignore > exception 2 other than to execute some code of dubious value. Could you elaborate on the obvious and dubious? After all, most exception handler are there to put things in a state as correct as possible. --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]