Exception Specification

Question

I know that this feature will be deprecated in C++0x, but for me as a total novice it seems like a good idea to have it. Could anyone explain to me why isn't a good idea?

Burhans

See stackoverflow.com/editing-help and stackoverflow.com/faq. This is not a forum. – Acclimatize

@John Saunders: it is an open-ended but legitimate technical question. There are reasons why the feature is being removed from the C++ standard, and they can be explained without subjectivity or argumentativeness. – Sheehy

@Jonathan: why are you directing that at me? – Acclimatize

@John Saunders: you might want to edit your comment to indicate that you were complaining about some irrelevant stuff that has since been edited out of the question (in its current form it's a fine question). – Fluster

@Daniel: @Jonathan: I did not downvote. The comment was meant for @atch, lacking any "private message" capability in SO. When I downvote, I say why. – Acclimatize

@John: I casually assumed given your comment that you had made the vote for 'close - argumentative and subjective'. Since your comments imply you had not done that, consider my comments withdrawn; I apologize. I had not looked at the downvotes on the question - and don't see any now. Nor had I looked at the editing history. – Sheehy

The purpose it serves is to make your program call terminate. You spend CPU seeing if you should call terminate. Not a great feature in the language from what I've researched. – Campo

Answer 1

Please see this detailed article by Herb Sutter. He has the most thorough explanation of the problems and short comings of their design.

A Pragmatic Look at Exception Specificiations

• http://www.gotw.ca/publications/mill22.htm

Thoroughfare

"Here’s what many people think that exception specifications do: - Guarantee that functions will only throw listed exceptions (possibly none)." Pure nonsense. That exactly what they do. "Enable compiler optimizations based on the knowledge that only listed exceptions (possibly none) will be thrown." That what exception specifications can do, and some major compilers actually do that. – Bowhead

@Bowhead did you read the full article? Based on your comment it sounds like you stopped after that sentence. – Thoroughfare

I can't believe C++0x was already underway in 2002. That was a long time coming! – Terpineol

@MarkRansom I takes a lot of repetition of wrong, absurd, ridiculous statements before they become the "truth". – Bowhead

"did you read the full article?" this is like asking me if I wish to waste more time reading this nonsense. The answer is obviously no. – Bowhead

That may be the worst GoTW I have ever read. Every "problem" Herb identifies is self-inflicted by the language spec and could have been fixed trivially in the new spec... For example, if C++11 simply allowed exception specifications in typedefs and changed the behavior to "undefined" for throwing an invalid exception, 90% of that article would be irrelevant. – Bannister

"That may be the worst GoTW I have ever read." Yes. "90% of that article would be irrelevant" Most of the article is irrelevant. Herb wanted to show that ES aren't so useful in most cases. But instead of explaining that, he makes crazy statements like saying that "Guarantee that functions will only throw listed exceptions (possibly none)."" is incorrect. – Bowhead

If anyone disagree me one, he could try to explain what "Guarantee that functions will only throw listed exceptions (possibly none)." could possibly mean, that isn't what the standard already enforce. – Bowhead

@curiousguy: The way in which that is guaranteed is not what most people would expect. A function will only throw listed exceptions because an attempt to throw an unlisted one would result in program termination. – Bruell

@Bruell It may not be what people who have not fully analysed the problem expect, but it is a useful guaranty, and a guaranty that can help some major compilers. (OTOH, Java behaviour may be what people expect - I don't know - but it is neither very useful for programmers, and the lack of real guaranty doesn't help optimisers.) The problem here probably isn't that Herb doesn't understand C++, it's his aggressive communication, the stunts he does, the way he manipulates. His behaviour has been considered frankly unacceptable by C++ committee members. When MSVC is involved, what a coincidence. – Bowhead

@Nemo: Getting rid of std::unexpected would be a rather significant change to existing code... I can't imagine many members of the committee would have been happy with making a well defined behavior undefined. – Ungodly

@Dennis: More significant than deprecating the entire feature?? – Bannister

@Nemo: In one case, a well defined program can suddenly break for no reason, while in the other case you get a compiler warning about using an out-of-date feature. So... yes, I would certainly classify the former as being more significant. – Ungodly

@Dennis: Specious argument; they could just as easily have deprecated std::unexpected. (And you do not really have to make it undefined behavior, since modern compilers implement zero-overheard try/catch... The point is to let the compiler assume that the throw spec is telling the truth to allow more optimal code. Herb's complaint that this is not true is a deficiency in MSVC and/or the spec, not a fundamental problem.) – Bannister

@Nemo: So exception specifications would not be deprecated, but part of their definition would require calling a deprecated function? There's a fuzzy line. But I don't honestly care if they're deprecated... all I'm saying is that making invalid specifications undefined behavior is a breaking change that wouldn't be considered by the committee. – Ungodly

@Bruell "The way in which that is guaranteed" whatever - it is guaranteed. The problem with Herb's rant is that he seems to claim the contrary. – Bowhead

Answer 2

As far as I understand it, an exception specification means:

I wan't you (the compiler) to generate extra code that makes sure that the exception is one of these types. If not call terminate please, we're toast. The extra checking would need to be put into the (implicit) exception handler (required to implement it) in every call.

Campo

Answer 3

Review of http://www.gotw.ca/publications/mill22.htm

Issue the First: A “Shadow Type System”

True, minor technical point, and easy to fix.

Issue the Second: (Mis)understandings

Here’s what many people think that exception specifications do:

His first point:

• Guarantee that functions will only throw listed exceptions (possibly none).

If this is what people think, it is very fine, because it is exactly what ES guarantee, by definition. Herb agrees in the same document:

(ES) Enforce at runtime that functions will only throw listed exceptions (possibly none).

His second point:

• Enable compiler optimizations based on the knowledge that only listed exceptions (possibly none) will be thrown.

This is also absolutely correct.

He explains why this second point is an incorrect belief with an example:

// Example 1(b) reprise, and two
// potential white lies:
//
int Gunc() throw();    // will throw nothing (?)

int Hunc() throw(A,B); // can only throw A or B (?)

Are the comments correct? Not quite. Gunc() may indeed throw something, and Hunc() may well throw something other than A or B! The compiler just guarantees to beat them senseless if they do… oh, and to beat your program senseless too, most of the time.

Because Gunc() or Hunc() could indeed throw something they promised not to, not only can’t the compiler assume it won’t happen (...)

Herb latter remark that "(ES) Enforce at runtime that functions will only throw listed exceptions (possibly none)." refute this "argument" too.

Both of Herb's 2 main points are obviously, absolutely, indisputably wrong, according to him.

What else can I add?

I believe that words have fix meaning, that can't be changed at will, for the sake of the "argument".

Bowhead

can anyone refute any point I make? Or I am being downvoted for contradicting the semi-God Herb Sutter? – Bowhead

Better question: Can you actually prove your points? You just say "this is like that, period.", which isn't very convincing. There's nothing wrong with contradicting someone. Both of Herb's 2 main points are obviously, absolutely, indisputably wrong.. Well, let's just assume it isn't as obvious to me as it is to you. Care to explain what exactly is so obvious? – Borst

Anyway, ask Herb. He pretty much agree with my points, and even writes that ES "Enforce at runtime that functions will only throw listed exceptions (possibly none)." Since the compiler enforce that only listed exception are thrown, it means it guaranteed that only listed exception. This is just what the language definition says anyway. It isn't like there is some room for argument - there is none. This obviously disprove his other point, that "Because Gunc() or Hunc() could indeed throw something they promised not to". – Bowhead

Note: I didn't downvote, and I don't understand them. That aside, there is a huge difference between guaranteeing something and enforcing something. It's a source of confusion because many people believe the former, while C++ only promises the latter. It's like the difference between "I guarantee you, that I'll never, ever steal something from you. If I try, I'll be shot." and "I guarantee you, that you'll never, ever notice I stole something from you, because by then you'll have been shot." (which is what happens in C++). – Borst

@Borst What will you do after your death? Do you have a plan? If you don't plan for your after-death, then you are contradicting Herb and yourself. – Bowhead