Given unexpected() why is there a terminate()
Author
I don't see the point of having both of these. terminate() is assumed to have to exit the program so it's more restricted, but why have it at all when the less restricted unexpected() exists?
They mean totally different things. terminate will kill your program, full stop, end of story; unexpected is intended to handle exceptions which do not fit into an exception filter specification in any applicable catch block. unexpected can also call a helper function (c.f. set_unexpected) which might do things like report the error situation to the user rather than just crashing out, etc.
[edit] Correction: this has nothing to do with catch but rather the throw specifier on a function... which, as Katie noted correctly below, is rarely used and actually IIRC isn't even supported fully by a few C++ implementations.
[Edited by - ApochPiQ on December 14, 2010 11:13:44 AM]
[edit] Correction: this has nothing to do with catch but rather the throw specifier on a function... which, as Katie noted correctly below, is rarely used and actually IIRC isn't even supported fully by a few C++ implementations.
[Edited by - ApochPiQ on December 14, 2010 11:13:44 AM]
Author
Quote:Original post by ApochPiQ
terminate will kill your program, full stop, end of story;....unexpected can also call a helper function (c.f. set_unexpected
Uh, see set_terminate()
My point is why allow the user to set a their own terminate helper when an unexpected helper can subsume all its functionality?
Because they are called in different circumstances.
Unexpected happens if (at run-time) an exception is thrown which is not currently in the active code's exception spec. These days no-one really uses x-specs because they're annoying.
Terminate is called under slightly ill-defined circumstances regarding failures to handle exceptions properly. Not being able to find a handler. Possibly throwing while throwing. That sort of thing.
You know, this stuff is in the language specs...
Unexpected happens if (at run-time) an exception is thrown which is not currently in the active code's exception spec. These days no-one really uses x-specs because they're annoying.
Terminate is called under slightly ill-defined circumstances regarding failures to handle exceptions properly. Not being able to find a handler. Possibly throwing while throwing. That sort of thing.
You know, this stuff is in the language specs...
Quote:Original post by Prune
Uh, see set_terminate()
My point is why allow the user to set a their own terminate helper when an unexpected helper can subsume all its functionality?
The helper invoked by set_terminate is required by the standard to terminate the program without fail. set_unexpected's helper is permitted to terminate the program or throw an exception, including re-throwing the original exception.
Quote:Original post by Katie
Terminate is called under slightly ill-defined circumstances regarding failures to handle exceptions properly.
Why do you refer to it as ill-defined? The C++ standard currently lists eight situations where terminate() is called (section 15.5.1) and none of them seem ill-defined.
Because (as I understand it) the list is not exclusive, and compilers MAY call terminate unbidden in other circumstances[1] - to comply with the standard they merely MUST call it in those 8.
[1] Borland does it during handling of erroneous pure virtual dispatches, IIRC.
[1] Borland does it during handling of erroneous pure virtual dispatches, IIRC.
Well, in the case of undefined behaviour the compiler is free to do what it wants, so that reasoning would apply to every other feature of C++ as well.
Quote:Original post by Konfusius
Luckily, exception specifications are being deprecated.
Heh, that's a proposal for the next round of C++ standardization, something like C++2x. Your use of the present tense in that sentence is ill-advised, since you mean "may or may not be removed by the time the next generation but one are confused by it."
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
