开发者

Exception Specification

开发者 https://www.devze.com 2022-12-24 02:20 出处:网络
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?Please see t

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?


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


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.


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

0

精彩评论

暂无评论...
验证码 换一张
取 消