微軟：請不要使用 Try/Catch

Web開發者發表於2014-01-05
微軟

　　作者：karlseguin  譯者：myownghost

　　異常處理已經被討論十幾年了。儘管在怎樣處理異常方面有一些普遍共識，但在使用方面還是有一些分歧。不恰當的異常處理很容易被發現，很容易被避免，這是評價程式碼質量的一個很重要的指標。我知道任何事情都沒有絕對一說，但一條普通的規則就是不要使用try/catch。

　　如果異常發生，你需要非常瞭解它產生的原因。如果一個意料之外的異常產生了。你還是讓程式自己崩潰吧。在大多數Web應用上就是這麼幹的，一個使用者的連線產生了異常不會影響其它使用者。（注：這篇文章發表的比較早，在NodeJS及其他單線非阻塞非同步程式設計中，一個執行緒崩潰了可能會影響到其它程式，不過現在已經有了比較好的解決方案，如Express，持久化session等）。所以最好的方法是做一個全域性的異常日誌，來記錄那些未處理的異常。我經常看到程式設計師寫處理錯誤的程式碼，以提高系統的質量。但使用者會抱怨系統不穩定，但程式設計師想破腦袋也不知道到底是什麼地方出了問題。

　　遺憾的是，在有些框架中他們也加了try/catch，看看下面的這個例子，在微軟的基礎框架裡：

private void LoadImage()
{
    if (this.image != null)
    {
        this.image.Dispose();
    }
    

    if (source != null)
    {
        try
        {
            source = Path.Combine(Canvas.ApplicationPath, source);
            image = new Bitmap(source);

           IImagingFactory factory = ImagingFactory.GetImaging();
           factory.CreateImageFromFile(source, out imagingImage);
        }
        catch{}
    }
}

　　這段程式碼截自Micrsoft的.NET Compact Framework的前端基礎框架(UI Framework)。上面的程式碼葬送了他們的框架，但這個東西被各種API呼叫，還廣泛使用了。這是非常簡單可怕的程式碼。為什麼麼他們能容忍異常從這段程式碼裡產生？這段程式碼意思著如果我讀取了一個不存在的圖片，如"images/critical_warning.png"，程式會繼續執行。這可能是你想要的一種情況，但不是所有情況，這樣的邏輯應該由應用程式處理，而不是在框架裡面。

　　真正需要異常的地方只有一個，就是全域性異常捕捉日誌，這樣可以幫助你找到所有異常產生的根本原因，並解決掉他們，然後你就可以安心睡大覺了。

　　一個使用try/catch來掩蓋異常的系統不是一個健康的系統。

　　原文 codebetter.com

相關文章