16

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?

Michael Myers
  • 188,989
  • 46
  • 291
  • 292
There is nothing we can do
  • 23,727
  • 30
  • 106
  • 194
  • See http://stackoverflow.com/editing-help and http://stackoverflow.com/faq. This is not a forum. – John Saunders Mar 23 '10 at 16:34
  • 4
    @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. – Jonathan Leffler Mar 23 '10 at 16:39
  • @Jonathan: why are you directing that at me? – John Saunders Mar 23 '10 at 16:42
  • 1
    @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). – Daniel Earwicker Mar 23 '10 at 16:44
  • @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. – John Saunders Mar 23 '10 at 16:49
  • @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. – Jonathan Leffler Mar 23 '10 at 17:54
  • 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. – doug65536 Dec 18 '12 at 04:34

3 Answers3

10

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

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • 1
    "_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. – curiousguy Nov 02 '11 at 20:56
  • @curiousguy did you read the full article? Based on your comment it sounds like you stopped after that sentence. – JaredPar Nov 02 '11 at 20:59
  • 1
    I can't believe C++0x was already underway in 2002. That was a long time coming! – Mark Ransom Nov 02 '11 at 21:02
  • @MarkRansom I takes a lot of repetition of wrong, absurd, ridiculous statements before they become the "truth". – curiousguy Nov 02 '11 at 21:06
  • "_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. – curiousguy Nov 02 '11 at 21:07
  • 1
    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. – Nemo Nov 02 '11 at 21:13
  • "_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. – curiousguy Nov 02 '11 at 21:22
  • 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. – curiousguy Nov 02 '11 at 22:13
  • @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. – K-ballo Nov 02 '11 at 22:15
  • @K-ballo 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. – curiousguy Nov 02 '11 at 22:55
  • @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. – Dennis Zickefoose Nov 02 '11 at 23:07
  • @Dennis: More significant than deprecating the entire feature?? – Nemo Nov 02 '11 at 23:23
  • @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. – Dennis Zickefoose Nov 02 '11 at 23:45
  • @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.) – Nemo Nov 02 '11 at 23:51
  • @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. – Dennis Zickefoose Nov 03 '11 at 00:19
  • @K-ballo "_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. – curiousguy Nov 23 '11 at 05:21
0

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.

doug65536
  • 6,562
  • 3
  • 43
  • 53
-2

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".

curiousguy
  • 8,038
  • 2
  • 40
  • 58
  • can anyone refute any point I make? Or I am being downvoted for contradicting the semi-God Herb Sutter? – curiousguy Nov 26 '11 at 01:54
  • 5
    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? – Xeo Nov 26 '11 at 05:37
  • 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_". – curiousguy Nov 26 '11 at 06:26
  • 4
    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++). – Xeo Nov 26 '11 at 06:49
  • @Xeo 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. – curiousguy Apr 06 '13 at 21:24