Exceptions
in [C++]
|
Next: C++/CLI limitations?
From: Maxim Yegorushkin on 3 Jul 2005 06:10 David Abrahams wrote: [] > > Not sure if exception throwing is exception-handling, but g++ allocates > > exceptions on the heap. > > > > http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc?rev=HEAD&content-type=text/vnd.viewcvs-markup > > AFAICT those exceptions are being "dynamically" allocated out of > static memory, in > > static one_buffer emergency_buffer[EMERGENCY_OBJ_COUNT]; > > That looks like the "magic memory" I was referring to. Am I missing > something? Only when malloc returns 0. That's why the *emergency* buffer. -- Maxim Yegorushkin <firstname.lastname(a)gmail.com> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 3 Jul 2005 06:11 Alf P. Steinbach wrote: > * David Abrahams -> Thiago R. Adams: > > > > > > > > If think that the most useful is: > > > template <classX , classA > inline void Assert(A assertion) { > > > DebugBreak(); // stops debug > > > > Stop execution so I can debug the program. Good! > > > > > if (!assertion ) throw X(); > > > } > > > > If the assertion fails when there is no debugger, how do you expect > > the program to recover? > > That's actually a good _C++_ question... ;-) > > First, the reason why one would like to 'throw' in this case, which is > usually not to recover in the sense of continuing normal execution, but > to recover enough to do useful logging, reporting and graceful exit on > an end-user system with no debugger and other programmer's tools > (including, no programmer's level understanding of what goes on). No recovery is possible after a failed assert. A failed assert means that we no longer know what's going on. Generally logging and reporting should be done at the earliest opportunity; if you attempt to "recover" you may be terminated and no longer be able to log or report. In some situations (ATM machine in the middle of a transaction, say) it might make sense to attempt recovery even when an assertion fails, if things can't possibly get any worse. This is extremely fragile, of course. You can't test how well the recovery works because by definition it is only executed in situations that your tests did not cover (if they did, you'd have fixed the code to no longer assert). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Maxim Yegorushkin on 3 Jul 2005 06:19 On Sat, 02 Jul 2005 14:23:03 +0400, Alf P. Steinbach <alfps(a)start.no> wrote: [] >> If the assertion fails when there is no debugger, how do you expect >> the program to recover? > > That's actually a good _C++_ question... ;-) > > First, the reason why one would like to 'throw' in this case, which is > usually not to recover in the sense of continuing normal execution, but > to recover enough to do useful logging, reporting and graceful exit on > an end-user system with no debugger and other programmer's tools > (including, no programmer's level understanding of what goes on). Why would one want a graceful exit when code is broken, rather than dying as loud as possible leaving a core dump with all state preserved, rather than unwound? std::abort() is a good tool for that. -- Maxim Yegorushkin <firstname.lastname(a)gmail.com> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach on 3 Jul 2005 18:29 * Maxim Yegorushkin: > > Why would one want a graceful exit when code is broken, rather than dying > as loud as possible leaving a core dump with all state preserved, rather > than unwound? std::abort() is a good tool for that. Because almost all code in existence, with the possible exception of TeX, is broken, and (1) end-users really don't like core dumps, (2) the maintainance team would like some information about what went wrong so that it can be fixed, and a discarded end-user's core dump doesn't do, (3) it's generally impolite and inconsiderate to wreck the city when one knows one's dying, but that can be the effect of a simple std::abort. Cheers, - Alf -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alf P. Steinbach on 3 Jul 2005 18:25
* Peter Dimov: > Alf P. Steinbach wrote: > > * David Abrahams -> Thiago R. Adams: > > > > > > > > > > > If think that the most useful is: > > > > template <classX , classA > inline void Assert(A assertion) { > > > > DebugBreak(); // stops debug > > > > > > Stop execution so I can debug the program. Good! > > > > > > > if (!assertion ) throw X(); > > > > } > > > > > > If the assertion fails when there is no debugger, how do you expect > > > the program to recover? > > > > That's actually a good _C++_ question... ;-) > > > > First, the reason why one would like to 'throw' in this case, which is > > usually not to recover in the sense of continuing normal execution, but > > to recover enough to do useful logging, reporting and graceful exit on > > an end-user system with no debugger and other programmer's tools > > (including, no programmer's level understanding of what goes on). > > No recovery is possible after a failed assert. A failed assert means > that we no longer know what's going on. Generally logging and reporting > should be done at the earliest opportunity; if you attempt to "recover" > you may be terminated and no longer be able to log or report. If "recovery" in the above means continuing on with normal execution, then the above is a sort of extremist version of my position. I would not go that far, especially in light of contrary facts. For example, one of the most used programs in the PC world, the Windows Explorer, does continue normal execution in this situation simply by restarting itself, so with this meaning of "recovery" the above is false. If "recovery" in the above means something generally more reasonable, like, cleaning up, then again that flies in the face of established fact. E.g., generally open files are closed by the OS whenever a process terminates, whatever the cause of the termination, and it's no big deal to define that as part of the application. In this sense of "recovery" the above therefore says it's impossible to write an OS in C++, and that's patently false, too. So what does the above mean, if anything? Is it, perhaps, a "proof", from principles, that hummingbirds can't fly? Then I'd suggest the proof technique and/or the principles are to blame. > In some situations (ATM machine in the middle of a transaction, say) it > might make sense to attempt recovery even when an assertion fails, if > things can't possibly get any worse. This is extremely fragile, of > course. You can't test how well the recovery works because by > definition it is only executed in situations that your tests did not > cover (if they did, you'd have fixed the code to no longer assert). Happily it's not the case that every ATM machine that encounters a failed assertion has to be discarded. :-) Cheers, - Alf -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |