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