|
作為程序員,我想很多人應(yīng)該都有過(guò)跟異常打交道的經(jīng)歷。而且相信也有很多人也都寫過(guò)catch(Exception e){//blabla}這種把所有未知異常一股腦兒捕獲并處理掉的代碼吧。不管是為敷衍客戶也好,讓程序繼續(xù)運(yùn)行以避免糟糕的用戶體驗(yàn)也罷,在微軟眼中,這種處理方式都是不對(duì)的,特別是當(dāng)你的程序是作為一個(gè)插件寄存在別的程序如VS,Offcie中時(shí),這種情況下對(duì)有些嚴(yán)重的異常如訪問(wèn)沖突我們更應(yīng)當(dāng)是讓程序結(jié)束而不是繼續(xù)運(yùn)行。
然而很多時(shí)候,我們并不清楚哪些異常是嚴(yán)重的,哪些是可以讓程序繼續(xù)運(yùn)行的,因?yàn)樵?NET 4.0以前,CLR會(huì)很忠實(shí)的把所有大大小小的異常一股腦兒的都拋給程序員處理。不過(guò)這個(gè)問(wèn)題在4.0以后會(huì)得到很好的解決了。因?yàn)閷?duì)有些嚴(yán)重的會(huì)引起進(jìn)程崩潰的異常的處理以后會(huì)由CLR來(lái)統(tǒng)一處理而不再交給我們可憐的程序員了。下面我將對(duì)這種異樣處理做一些簡(jiǎn)單的介紹。
為什么需要Corrupted State Exceptions
異常有大有小,小的如字符串為空,這些一般是用戶輸入問(wèn)題,它不會(huì)引起整個(gè)程序或者系統(tǒng)中相關(guān)進(jìn)程出現(xiàn)崩潰的情況;大的如訪問(wèn)沖突異常,這可能是你的程序在做一些可能會(huì)引起操作系統(tǒng)崩潰的事情,這種異常一般都比較嚴(yán)重,一般如果出現(xiàn)這種異常,通常程序應(yīng)該做的是結(jié)束當(dāng)前進(jìn)程,然后老老實(shí)實(shí)向用戶報(bào)告你犯傻了并提示他重啟程序。不過(guò)在.NET 4.0以前,CLR是很相信程序員不會(huì)搞出一些諸如catch(Exception e){return;}這種不負(fù)責(zé)任的代碼的,因此它不分輕重緩急,只要是異常,它統(tǒng)統(tǒng)都會(huì)拋出來(lái),這里面不僅僅有托管代碼的異常,也有一些.NET程序員不太好看懂的COM和WIN32異常。CLR相信程序員在捕獲異常的時(shí)候會(huì)只處理他們清楚的異常,但很多時(shí)候,作為開發(fā)人員,由于上面有老板,下面有客戶,我們真的很難做人,想想如果老板動(dòng)不動(dòng)就聽(tīng)又客戶抱怨他們只不過(guò)點(diǎn)了兩下按鈕程序就報(bào)錯(cuò)然后結(jié)束了,他還能給你加薪么?雖然很多時(shí)候我們清楚我們的代碼不會(huì)出問(wèn)題,但我們很難保證天時(shí)地利人和樣樣俱全,為了給老板和客戶一個(gè)交代,這時(shí)候很多人都會(huì)選擇去捕獲所有的異常,然后記錄下異常信息,然后程序繼續(xù)彪悍的跑下去。
看似一些都很完美,客戶不會(huì)再像以前那么頻繁的抱怨程序down掉,老板也就高興了。但有人不高興。小的未知異常當(dāng)然不會(huì)捅大的簍子,但對(duì)有些可能導(dǎo)致程序甚至操作系統(tǒng)崩潰的異常如果不中斷程序的話可能影響的就是一大片了。這個(gè)時(shí)候客戶可能不會(huì)抱怨你,但他會(huì)抱怨微軟出了個(gè)爛操作系統(tǒng),一天到晚藍(lán)屏,或者他會(huì)抱怨微軟的Office或者IE太爛,他只不過(guò)加載了一個(gè)插件,結(jié)果整個(gè)Outlook就報(bào)錯(cuò)崩掉了。你是省事了,但微軟得來(lái)被黑鍋,而且他還不知道這個(gè)黑鍋里面到底是咋回事。
當(dāng)然上面是玩笑,不過(guò)不管怎樣,從程序安全和穩(wěn)定的角度來(lái)看catch(Exception e)確實(shí)不是一個(gè)好的編程習(xí)慣,然而木已成舟,既然無(wú)法避免程序員偷懶,微軟只能采取一些補(bǔ)救措施了,這里他們?cè)贑LR 4中添加了新的異常處理機(jī)制,自4.0以后,CLR不會(huì)主動(dòng)給你拋出所有異常了,對(duì)于那些它認(rèn)為是危險(xiǎn)的,可能導(dǎo)致進(jìn)程崩潰的異常它會(huì)標(biāo)記為Corrupted State Exception并自己處理掉而不是拋給程序員來(lái)做,如AccessViolationException這種繼承自SystemException的異常就會(huì)被當(dāng)做Corrupted State Exception來(lái)處理。不過(guò)這里要注意的是,僅僅異常類型是可能會(huì)危險(xiǎn)級(jí)別的異常還不夠,CLR還會(huì)判斷拋出異常的所有者,如果它發(fā)現(xiàn)是由操作系統(tǒng)拋出的訪問(wèn)沖突則會(huì)認(rèn)為這是狀態(tài)崩潰異常,但如果異常是由用戶代碼拋出,則CLR不會(huì)對(duì)其做特殊處理,它仍然會(huì)像以前一樣將其正常拋出。
如何繼續(xù)捕獲Corrupted State Exceptions
那么CLR包了這塊的異常處理是不是意味著以后我們程序員就沒(méi)得選只能老老實(shí)實(shí)向用戶報(bào)告我們的產(chǎn)品不行,然后讓老板炒我們魷魚了呢?那些.NET 4.0以前發(fā)布的,處處是漏洞的產(chǎn)品我們?cè)趺刺幚恚?/p>
雖然微軟不再那么相信程序員是負(fù)責(zé)人的人,但它也做那么絕。雖然默認(rèn).NET 4.0以后CLR會(huì)處理這些異常,程序員也不用再操心這些危險(xiǎn)的異常了。但你仍然可以繼續(xù)你以往敷衍上司的做法。并且微軟還提供了兩種方式。
首先對(duì)于以往的程序,微軟提供了兩種選擇:
1. 如果你想把以往舊的代碼在.NET Framework 4.0下編譯但又不想改代碼的話,你可以在你的程序的配置文件中添加一個(gè)新的節(jié)點(diǎn):legacyCorruptedStateExceptionsPolicy=true,它使得你的代碼仍能按照以前處理異常的方式來(lái)繼續(xù)運(yùn)行。
2. 如果你不想有任何改變,直接把以前已經(jīng)編譯好的程序在.NET Framework 4.0下運(yùn)行則不需要任何改變,CLR會(huì)保證所有的異常仍然按照以往的方式處理。
其次,對(duì)于那些使用了.NET Framework 4.0 但又想自己處理這些導(dǎo)致程序狀態(tài)崩潰的異常,微軟同樣提供了選擇,他們?cè)?NET 4.0中增加了一個(gè)新的命名空間:System.Runtime.ExceptionServices,這里面有個(gè)特性類叫做HandleProcessCorruptedStateExceptionsAttribute,你只需要在相應(yīng)方法上添加這個(gè)屬性,CLR就會(huì)把所有的異常處理交給你做,就像以前一樣。e.g.

// This program runs as part of an automated test system so you need
// to prevent the normal Unhandled Exception behavior (Watson dialog).
// Instead, print out any exceptions and exit with an error code.
[HandledProcessCorruptedStateExceptions]
public static int Main()
{
try
{
// Catch any exceptions leaking out of the program
CallMainProgramLoop();
}
catch (Exception e) // We could be catching anything here
{
// The exception we caught could have been a program error
// or something much more serious. Regardless, we know that
// something is not right. We'll just output the exception
// and exit with an error. We won't try to do any work when
// the program or process is in an unknown state!
System.Console.WriteLine(e.Message);
return 1;
}
return 0;
}
//當(dāng)然要注意的是這個(gè)特性只能應(yīng)用在方法上。
NET技術(shù):.NET 4.0新特性-- Corrupted State Exceptions,轉(zhuǎn)載需保留來(lái)源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除,多謝。