本文將為大家介紹的是.NET 4.0中異常處理方面的新特性Corrupted State Exceptions，這項新特性能讓大家更方便的查找錯誤，希望對大家有所幫助。

作為程序員，我想很多人應(yīng)該都有過跟異常打交道的經(jīng)歷。而且相信也有很多人也都寫過catch(Exception e){//blabla}這種把所有未知異常一股腦兒捕獲并處理掉的代碼吧。不管是為敷衍客戶也好，讓程序繼續(xù)運行以避免糟糕的用戶體驗也罷，在微軟眼中，這種處理方式都是不對滴，特別是當(dāng)你的程序是作為一個插件寄存在別的程序如VS,Offcie中時，這種情況下對有些嚴重的異常如訪問沖突我們更應(yīng)當(dāng)是讓程序結(jié)束而不是繼續(xù)運行。然而很多時候，我們并不清楚哪些異常是嚴重的，哪些是可以讓程序繼續(xù)運行的，因為在.NET 4.0以前，CLR會很忠實的把所有大大小小的異常一股腦兒的都拋給程序員處理。不過這個問題在4.0以后會得到很好的解決了。因為對有些嚴重的會引起進程崩潰的異常的處理以后會由CLR來統(tǒng)一處理而不再交給我們可憐的程序員了。下面我將對這種異樣處理做一些簡單的介紹。

為什么需要Corrupted State Exceptions

異常有大有小，小的如字符串為空，這些一般是用戶輸入問題，它不會引起整個程序或者系統(tǒng)中相關(guān)進程出現(xiàn)崩潰的情況；大的如訪問沖突異常，這可能是你的程序在做一些可能會引起操作系統(tǒng)崩潰的事情，這種異常一般都比較嚴重，一般如果出現(xiàn)這種異常，通常程序應(yīng)該做的是結(jié)束當(dāng)前進程，然后老老實實向用戶報告你犯傻了并提示他重啟程序。不過在.NET 4.0以前，CLR是很相信程序員不會搞出一些諸如catch(Exception e){return;}這種不負責(zé)任的代碼的，因此它不分輕重緩急，只要是異常，它統(tǒng)統(tǒng)都會拋出來，這里面不僅僅有托管代碼的異常，也有一些.NET程序員不太好看懂的COM和WIN32異常。CLR相信程序員在捕獲異常的時候會只處理他們清楚的異常，但很多時候，作為開發(fā)人員，由于上面有老板，下面有客戶，我們真的很難做人，想想如果老板動不動就聽又客戶抱怨他們只不過點了兩下按鈕程序就報錯然后結(jié)束了，他還能給你加薪么？雖然很多時候我們清楚我們的代碼不會出問題，但我們很難保證天時地利人和樣樣俱全，為了給老板和客戶一個交代，這時候很多人都會選擇去捕獲所有的異常，然后記錄下異常信息，然后程序繼續(xù)彪悍的跑下去。

看似一些都很***，客戶不會再像以前那么頻繁的抱怨程序down掉，老板也就高興了。但有人不高興。小的未知異常當(dāng)然不會捅大的簍子，但對有些可能導(dǎo)致程序甚至操作系統(tǒng)崩潰的異常如果不中斷程序的話可能影響的就是一大片了。這個時候客戶可能不會抱怨你，但他會抱怨微軟出了個爛操作系統(tǒng)，一天到晚藍屏，或者他會抱怨微軟的Office或者IE太爛，他只不過加載了一個插件，結(jié)果整個Outlook就報錯崩掉了。你是省事了，但微軟得來被黑鍋，而且他還不知道這個黑鍋里面到底是咋回事。

當(dāng)然上面是玩笑，不過不管怎樣，從程序安全和穩(wěn)定的角度來看catch(Exception e)確實不是一個好的編程習(xí)慣，然而木已成舟，既然無法避免程序員偷懶，微軟只能采取一些補救措施了，這里他們在CLR 4中添加了新的異常處理機制，自4.0以后，CLR不會主動給你拋出所有異常了，對于那些它認為是危險的，可能導(dǎo)致進程崩潰的異常它會標記為Corrupted State Exception并自己處理掉而不是拋給程序員來做，如AccessViolationException這種繼承自SystemException的異常就會被當(dāng)做Corrupted State Exception來處理。不過這里要注意的是，僅僅異常類型是可能會危險級別的異常還不夠，CLR還會判斷拋出異常的所有者，如果它發(fā)現(xiàn)是由操作系統(tǒng)拋出的訪問沖突則會認為這是狀態(tài)崩潰異常，但如果異常是由用戶代碼拋出，則CLR不會對其做特殊處理，它仍然會像以前一樣將其正常拋出。

如何繼續(xù)捕獲Corrupted State Exceptions

那么CLR包了這塊的異常處理是不是意味著以后我們程序員就沒得選只能老老實實向用戶報告我們的產(chǎn)品不行，然后讓老板炒我們魷魚了呢？那些.NET 4.0以前發(fā)布的，處處是漏洞的產(chǎn)品我們怎么處理？

雖然微軟不再那么相信程序員是負責(zé)人的人，但它也做那么絕。雖然默認.NET 4.0以后CLR會處理這些異常，程序員也不用再操心這些危險的異常了。但你仍然可以繼續(xù)你以往敷衍上司的做法。并且微軟還提供了兩種方式。

首先對于以往的程序，微軟提供了兩種選擇：

1. 如果你想把以往舊的代碼在.NET Framework 4.0下編譯但又不想改代碼的話，你可以在你的程序的配置文件中添加一個新的節(jié)點：legacyCorruptedState­­ExceptionsPolicy=true，它使得你的代碼仍能按照以前處理異常的方式來繼續(xù)運行。

2. 如果你不想有任何改變，直接把以前已經(jīng)編譯好的程序在.NET Framework 4.0下運行則不需要任何改變，CLR會保證所有的異常仍然按照以往的方式處理。

其次，對于那些使用了.NET Framework 4.0 但又想自己處理這些導(dǎo)致程序狀態(tài)崩潰的異常，微軟同樣提供了選擇，他們在.NET 4.0中增加了一個新的命名空間：System.Runtime.ExceptionServices，這里面有個特性類叫做HandleProcessCorruptedStateExceptionsAttribute，你只需要在相應(yīng)方法上添加這個屬性，CLR就會把所有的異常處理交給你做，就像以前一樣。e.g.

view sourceprint?01 // 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)然要注意的是這個特性只能應(yīng)用在方法上。

總結(jié)

異常處理常常是程序員心中的一塊心病，盡管微軟認為自己得為縱容程序員濫用異常捕獲負責(zé)然后添加了這個新的異常處理機制，不過在他們看來，那種catch(Exception e)的行為仍然是不對的。他們認為異常的出現(xiàn)表明當(dāng)前程序的狀態(tài)出現(xiàn)了問題，而程序員應(yīng)當(dāng)清楚這些錯誤的狀態(tài)所造成的后果，所以程序員應(yīng)當(dāng)捕獲具體的異常并作出正確的處理，而不是因為偷懶或者省事去簡單處理所有異常。

原文標題：.NET 4.0新特性-- Corrupted State Exceptions

鏈接：http://www.cnblogs.com/jujusharp/archive/2010/01/05/handling-corrupted-state-exceptions-in-dot-net-4-0.html