Sign in to follow this  
Prune

Given unexpected() why is there a terminate()

Recommended Posts

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]

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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."

Share this post


Link to post
Share on other sites
"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."

Yes. That's entirely in keeping with what I said.

So the circumstances under which terminate can be called are at least a list of 8 things in the spec, plus whatever undefined things the compiler feels like.

So that would be my original "slightly ill-defined" statement.



You see, and now I'm wondering if I should go get a head MRI because I'm under this impression that I'm writing English in reasonably complete sentences.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bregma
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."


That's right. What I'm getting at is that exception specifications will go away and are presently rarely used anyway (as hinted at by that document), so IMHO, as an application writer, it is reasonable to not bother with them at all until they will go away for good.

Share this post


Link to post
Share on other sites
Quote:
Original post by Katie
You see, and now I'm wondering if I should go get a head MRI because I'm under this impression that I'm writing English in reasonably complete sentences.


Everyone wonders about this after witnessing Sneftel talking about C++. ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this