Exceptions
in [C++]
|
Next: C++/CLI limitations?
From: Niklas Matthies on 3 Jul 2005 22:27 On 2005-07-03 10:19, Maxim Yegorushkin wrote: > On Sat, 02 Jul 2005 14:23:03 +0400, Alf P. Steinbach 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? Because the customer expects and demands it. Actually, more often than not the customer even demands graceful resumption. -- Niklas Matthies [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Albrecht Fritzsche on 3 Jul 2005 22:27 >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? Because your code is integrated into another program. This program might, for instance, give some guarantees while your code is working - like saving all prior actions etc... If all your program can do is "dying loud" then the integrators won't be exactly happy. Ali [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nicola Musatti on 4 Jul 2005 07:08 Maxim Yegorushkin wrote: [...] > 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. You and Peter seem to assume that there can be no knowledge about how and where the code is broken. I believe that this depends on the kind of application and how modular it is. In many interactive applications it only takes a little care to ensure that you can always abort the current operation and go back to the main event loop as if no problem ever took place. I'm working all day long with an IDE that throws at me any kind of unexpected exceptions; when that happens I usually restart the #@! thing, but the few times I did try to carry on, I never encountered any problems. Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Motti Lanzkron on 4 Jul 2005 07:07 On 1 Jul 2005 13:02:33 -0400, "Thiago R. Adams" <thiago.adams(a)gmail.com> wrote: >> Broken preconditions should almost always be handled with an assert >> and not an exception. An exception will usually cause a great deal of >> code to be executed before you get a chance to diagnose the problem. > >In much cases asserts work as comentary only; >for example: > >void f(pointer *p){ > assert(p != 0); > p->f(); >} > >With exceptions the code will be response the error. > >The TC++PL has an example: > >template <classX , classA > inline void Assert(A assertion) { > if (!assertion ) throw X(); >} > >If think that the most useful is: >template <classX , classA > inline void Assert(A assertion) { > DebugBreak(); // stops debug > if (!assertion ) throw X(); >} We have some macros that do something similar: They're macros so that the original __LINE__ and __FILE__ are kept and since a lot of code is COM, errors are indicated by return codes. Something along the lines of: #define ASSERT_OR_RETURN(cond, ret) \ if( cond ) \ ; \ else { \ assert(false && #cond); \ return ret; \ } And it's used as: ASSERT_OR_RETURN( pArg != NULL, E_POINTER); As a side note, this has got some criticism that claims that static code analyzers can't correctly analyze functions that use such constructs. Is this true? I'm not familiar with such tools but it seems that they should have the option of some macro expansion. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 4 Jul 2005 13:43
Alf P. Steinbach wrote: > * Peter Dimov: >> Alf P. Steinbach wrote: >>> 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, You said: "one would like to 'throw' in this case" ... "to recover enough to do useful logging, reporting and graceful exit." So I assumed that by "recovery" you mean "stack unwinding" (with its usual side effects), because this is what 'throw' does. > 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. Normal execution doesn't involve killing the host process, even if it's automatically restarted after that. Exit+restart is recovery, for a different definition of "recovery", but it's not performed by throwing an exception. > 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. No, cleaning up open files after a process dies is not recovery, and it's not performed by throwing an exception. > So what does the above mean, if anything? It means that performing stack unwinding after a failed assert is usually a bad idea. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |