在異常捕獲加入
C++
幾年后，標準化委員會加入了一個叫做異常規(guī)范的的補充特性。本文將介紹異常規(guī)范并質(zhì)疑其可用性。
?????
問題
??????
考慮下面的函數(shù)原型：
?????? void validate(int code);
??????
通常，第三方的庫把相似的聲明分類放在頭文件里面，把實現(xiàn)對用戶隱藏起來。用戶如何知道這個函數(shù)是否拋出一個異常和在什么情況下拋出異常呢？顯然，這種聲明并沒有提供任何線索。
Validate()
可能是一個拋出異常的函數(shù)，甚至可能是一個完全不知道
C++
異常的
C
函數(shù)拋出了異常。
??????
異常在
1989
年加入了
C++
。幾年的困擾使得標準化委員會加入了異常規(guī)范。
異常規(guī)范基礎(chǔ)
??????
一個異常規(guī)范描述了一個函數(shù)允許拋出哪些異常。沒有列在異常規(guī)范里的異常將不會從函數(shù)里拋出。一個異常規(guī)范包括在函數(shù)的參數(shù)列表后面添加的關(guān)鍵字
throw
。在
throw
的后面是一個異常列表。
void validate(int code) throw (bad_code, no_auth);
??????
異常規(guī)范并不是函數(shù)原型的一部分。因此，它不影響重載函數(shù)。那就是說，函數(shù)指針和成員函數(shù)指針可以包括一個異常規(guī)范
:
void (*pf)(int) throw(string, int);
?????? pf
是指向一個可能拋出
string
類型或者
int
類型異常的函數(shù)的指針。你可以讓其指向一個與其有同樣異常規(guī)范限制的函數(shù)或者一個異常規(guī)范限制更嚴格的函數(shù)。如果異常規(guī)范
A
的異常集合是異常規(guī)范
B
的異常集合的子集，稱
A
比
B
的限制更嚴格。換句話說，
A
包含的每個異常都在
B
中，但是反過來卻不是這樣的。
//more restrictive than pf:
void e(int) throw (string);
//as restrictive as pf:
void f(int) throw (string, int);
//less restrictive than pf:
void g(int) throw (string, int, bool);
pf=e; //fine
pf=f; //fine
pf=g; //error
異常規(guī)范和繼承
??????
一個重載虛函數(shù)不能擴展在基類的函數(shù)里聲明的異常集，但是可以縮小它。
??????
讓我們看一個實際的例子。加入你有下面的類層次結(jié)構(gòu)以及相關(guān)的異常類集合
:
class clock_fault{/*..*/};
class Exception {/*..*/}; //base for other exceptions
class hardware_fault: public Exception {/*..*/};
class logical_error: public Exception {/*..*/};
class invalid_protocol: public Exception{/*..*/};
?
class RemovableDevice
{
public:
?virtual int
?connect(int port) throw(hardware_fault, logical_error);
?virtual int
?transmit(char * buff) throw(invalid_protocol);
};
?
class Scanner: public RemovableDevice
{
public:
?int connect(int port) throw(hardware_fault); //OK
?int transmit(char * buff)
? throw(invalid_protocol, clock_fault);//Error
};
RemovableDevice::connect()
的異常規(guī)范允許它拋出
hardware_fault
和
logical_error
異常
(
以及任何派生自這些類的異常
)
。重載函數(shù)
Scanner::connect()
縮小了這個規(guī)范。從這個函數(shù)拋出任何除
hardware_fault
以外的異常，包括
logical_error,
都不允許。
Scanner::transmit()
的異常規(guī)范的形式是錯誤的。它包括一個沒有在
RemovableDevice::transmit()
的異常規(guī)范里出現(xiàn)的異常
:clock_fault
。如果你嘗試編譯這段代碼，編譯器將提示異常規(guī)范沖突。
空的異常規(guī)范和遺漏異常規(guī)范
??????
一個沒有異常規(guī)范的函數(shù)允許所有的異常。一個異常規(guī)范為空的函數(shù)不允許任何異常：
class File
{
public:
?int open(FILE *ptr); //may throw any exception
?int close(FILE *ptr) throw(); //doesn't throw
};
當你聲明一個空的異常規(guī)范，你需要總是檢查是否有破壞它的風險。
異常規(guī)范的實現(xiàn)
??????
異常規(guī)范在運行時實現(xiàn)。當一個函數(shù)破壞了它的異常規(guī)范，
std::unexpected()
將被調(diào)用。
Unexpected()
調(diào)用一個之前通過
std::set_unexpected()
注冊的用戶定義函數(shù)。如果沒有通過
set_unexpected()
注冊函數(shù)，
unexpected()
調(diào)用
std::terminate()
來無條件終止程序運行。
異常規(guī)范——理論與實踐
??????
異常規(guī)范似乎是備受贊揚的東西。它們不只明確的在文檔上提出了一種函數(shù)的異常策略，而且
C++
也實現(xiàn)了它們。
??????
在開始，
C++
社區(qū)強烈的歡迎它們。許多指南和手冊作者開始在所有的地方使用它們。課本里的一個典型的類就像這樣：
class Foo
{
public:
?Foo() throw();
?~Foo() throw();
?Foo(const Foo& ) throw();
?Foo& operator=(const Foo &) throw()
//...etc., etc.
};
沒過多久程序員們就意識到異常規(guī)范相當?shù)穆闊．惓Ｊ莿討B(tài)的。不可能總是預見得到在運行時將會拋出哪些異常。如果一個有異常規(guī)范的函數(shù)
g()
調(diào)用一個有更小限制或者沒有限制的異常規(guī)范的函數(shù)
f(),
將會發(fā)生什么呢？
void f();
void g() throw(X)
{
?f(); //OK, but problematic
}
如果
f()
拋出一個不是
X
的異常，
g()
可能會破壞它的異常規(guī)范。
性能是另一個問題。異常總會產(chǎn)生性能代價。執(zhí)行異常規(guī)范還會產(chǎn)生額外的代價，因為實現(xiàn)實在運行時執(zhí)行的。
因為這些原因以及其他原因，異常規(guī)范迅速失去了它們的光彩。今天，你很難再在新的代碼或者課本
(
諷刺的是，第一批采用它們的課本也是第一批悄悄丟棄它們的
)
里發(fā)現(xiàn)它們。
結(jié)論
??????
異常規(guī)范是那些理論上似乎可行但是在現(xiàn)實世界被證明是聲明狼藉的特性之一。你可能會問我為什么花時間來討論它們。有兩點原因：第一，傳統(tǒng)的使用異常規(guī)范的代碼依然存在。讀這樣的代碼——更重要的是正確的使用它，要求熟悉這一屬性。
第二，異常規(guī)范在程序語言設(shè)計上上了一課。很多程序語言采用
C++
的異常捕獲模型，包括異常規(guī)范。當
C++
社區(qū)意識到異常規(guī)范沒有那么好時，那些語言已經(jīng)沉迷于這一特性的好處。
今天，有一種要求對
C++
加入
finally
的壓力。這種架構(gòu)在沒有析構(gòu)函數(shù)的
Java
里面很有用。盡管如此，在
C++
語言里，
finally
是多余的，因為在一件異常事件里，你可以通過在析構(gòu)函數(shù)里實現(xiàn)無條件清理操作。因此為什么要提議
finally
呢？很簡單，因為
Java
的程序員仍然按照
Java
的思維方式編寫
C++
代碼。異常規(guī)范告訴我們務(wù)必必須對添加一個沒有被徹底測試的特性非常小心。
?
翻譯自：
http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=109&rl=1
?
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1452376