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