847
如何編寫沒有Try/Catch的程序
在上麵一篇文章《談談關於MVP模式中V-P交互問題》中，我提到最近一直為一個項目進行Code Review的工作，從中發現了一些問題，同時也有了一些想法。上次談到如何正確編寫服務MVP規範的程序，這次我們來關注一個我們每天都會麵對的問題：異常處理。
一、異常處理不簡單
個人覺得，異常處理對於程序員來說，尤其是對於那些初級.NET程序員來說，是最為熟悉的同時也是最難掌握的。說它熟悉，因為僅僅就是Try/Catch而已。說它難以掌握，很多開發人員卻說不清楚Try/Catch應該置於何處？什麼情況下需要對異常進行日誌記錄？什麼情況下需要對異常進行封裝？什麼情況下需要對異常進行替換？對於捕獲的異常，在什麼情況下需要將其再次拋出？什麼情況下則不需要。總之，異常處理沒有我們想象的那麼簡單。
無論對於何種類型的應用，異常處理都是必不可少的。合理的異常處理應該是場景驅動的，在不同的場景下，采用的異常處理策略往往是不同的。異常處理的策略應該是可配置的，因為應用程序出現怎樣的異常往往是不可預測的，現有異常策略的不足往往需要在真正出現某種異常的時候才會體現出來,所以我們需要一種動態可配置的異常處理策略維護方式。目前有一些開源的異常處理框架提供了這種可配置的、場景驅動的異常處理方式，EnterLib的Exception Handling Application Block就是一個不錯的選擇。
二、異常處理對於最終的開發人員是透明的
“異常處理對於最終的開發人員是透明的”，可能這句話說得有點過頭。但是，就我個人的項目經驗來講，這是一種理想的狀態。由於異常策略是一般是通過配置動態配置的，不需要反映在代碼上麵。如果能夠通過框架的方式提供異常處理的實現，使開發人員無需編寫任何異常處理的代碼，隻需要關注業務流程的實現就可以了，這不僅能夠提高開發的效率，也能夠提高係統的可維護性。
我們目前的項目是一個典型的分布式應用，所有的業務流程的處理和數據訪問都實現在服務端，最終以WCF服務的形式暴露給客戶端（Smart Client）和第三方應用。所有客戶端和服務端從邏輯上具有相應的層次劃分，但是異常處理僅僅實現在兩個地方，一個地方是WCF服務本身，另一個實現UI層。忘了說明一點，我們項目直接將EnterLib的Exception Handling Application Block作為我們的異常處理框架。對於服務端的異常處理來說，我們通過WCF與EHAB的集成來實現的（《WCF與Exception Handling AppBlock集成》），所以不需要開發人員添加任何一句Try/Catch代碼。但是客戶端來說，對於某個控件的事件來說，由於UI本身就是處於整個調用棧的最頂層，很難通過基於AOP的攔截機製來實現對異常處理的動態注入，所以客戶端會出現非常類似於下麵代碼所示的Try/Catch。
1: private void buttonCalculate_Click(object sender, EventArgs e)
2: {
3: try
4: {
5: //
6: }
7: catch (Exception ex)
8: {
9: if (ExceptionPolicy.HandleException(ex, "policyName"))
10: {
11: throw;
12: }
13: }
14:
15: }
三、通過編寫公共方法的形式實現代碼的重用
1: public void Invoke(Action action)
2: {
3: try
4: {
5: action();
6: }
7: catch (Exception ex)
8: {
9: if (ExceptionPolicy.HandleException(ex, "data access policy"))
10: {
11: throw;
12: }
13: }
14: }
在調用的時候，隻需要將相應的操作以Action類型的Delegate的形式傳入Invoke方法即可。但是這樣，也會在所有控件處理事件中出現重複的Invoke調用，雖然重複的代碼行數減少了，但是還是會出現大規模的重複。接下裏我來介紹另一種解決方法。
四、對EventHandler進行封裝
認真分析上麵的需求，我們的根本目的就是讓執行事件處理程序的時候在外麵人為地套一個Try/Catch，並對捕獲的異常進行相應的處理。從這個意義上講，如果我們能夠對EventHandler或者ExventHandler<TEventArgs>進行相應的封裝，就能實現我們需要的目的。
可能我這樣說，你不會太明白，我們還是通過代碼來說話好了。在下麵我創建了一個用於封裝EventHandler對象的EventHandlerWrapper類型。我們知道EventHandler是一個Delegate，而Delegate由兩部分組成：表示操作本身的MethodInfo和操作執行的目標對象，分別通過屬性Method和Target表示。在執行EventHandler的時候，就是通過反射的方式調用MethodInfo的Invoke方法，並將目標對象和相應的參數傳入該方法而已。
1: using System;
2: using System.Diagnostics;
3: using System.Reflection;
4: using System.Text;
5: using System.Windows.Forms;
6: namespace ProgramingWithoutTryCatch
7: {
8: public class EventHandlerWrapper
9: {
10: public object Target
11: { get; private set; }
12:
13: public MethodInfo Method
14: { get; private set; }
15:
16: public EventHandler Hander
17: { get; private set; }
18:
19: public EventHandlerWrapper(EventHandler eventHandler)
20: {
21: if (null == eventHandler)
22: {
23: throw new ArgumentNullException("eventHandler");
24: }
25:
26: this.Target = eventHandler.Target;
27: this.Method = eventHandler.Method;
28: this.Hander += Invoke;
29: }
30:
31: public static implicit operator EventHandler (EventHandlerWrapper eventHandlerWrapper)
32: {
33: return eventHandlerWrapper.Hander;
34: }
35:
36: private void Invoke(object sender, EventArgs args)
37: {
38: try
39: {
40: this.Method.Invoke(this.Target, new object[] { sender, args });
41: }
42: catch (TargetInvocationException ex)
43: {
44: StringBuilder message = new StringBuilder();
45: message.AppendLine(string.Format("Message: {0}", ex.InnerException.Message));
46: message.AppendLine(string.Format("Exception Type: {0}", ex.InnerException.GetType().AssemblyQualifiedName));
47: message.AppendLine(string.Format("Stack Trace: {0}", ex.InnerException.StackTrace));
48: EventLog.WriteEntry("Application", message.ToString());
49: MessageBox.Show(ex.InnerException.Message + Environment.NewLine + "For detailed information, please view event log", string.Empty, MessageBoxButtons.OK, MessageBoxIcon.Error);
50: }
51: }
52: }
53: }
EventHandlerWrapper通過EventHandler對象創建，並將EventHandler的Target和Method賦值給EventHandlerWrapper的同名屬性。此外，EventHandlerWrapper得Invoke方法中，將對Method的調用放在一個Try/Catch中，並對捕獲的異常進行簡單的處理：記錄到EventLog中在通過MessageBox將相關異常信息顯示出來。而EventHandlerWrapper的Handler屬性就是對該Invoke方法的直接反映。最後定義了一個隱式類型轉換將EventHandlerWrapper直接轉換成EventHandler。轉化後返回的就是反映Invoke方法的Handler屬性。為了演示，我寫了一個簡單的計算器的應用。該應用運行後的界麵如右圖所示，這是一個進行簡單除法運算的計算器。
下麵是相關的代碼：
1: using System;
2: using System.Windows.Forms;
3: namespace ProgramingWithoutTryCatch
4: {
5: public partial class Form1 : Form
6: {
7: public Form1()
8: {
9: InitializeComponent();
10: this.buttonCalculate.Click += new EventHandlerWrapper(buttonCalculate_Click);
11: }
12:
13: private void buttonCalculate_Click(object sender, EventArgs e)
14: {
15: int op1 = int.Parse(this.textBoxOp1.Text);
16: int op2 = int.Parse(this.textBoxOp2.Text);
17: int result = op1 / op2;
18: this.textBoxResult.Text = result.ToString();
19: }
20: }
21: }
代碼非常簡單，需要注意的是在對Button的Click事件進行注冊的時候，我們直接使用的時我們上麵創建的EventHandlerWrapper，這和真正進行事件注冊的方式幾乎一致。當你輸入非數字或者被除數設置為的時候，會拋出異常，異常的相關信息會直接寫入EventLog，並將異常消息通過MessageBox顯示出來，如下圖所示：
五、通過EventHandlerWrapper的寫法實現其他的功能
EventHandlerWrapper實際上為了展示了對EventHandler進行封裝的方式，異常處理並非其獨有的應用場景。如果你看過我的文章《事件 (Event)，絕大多數內存泄漏（Memory Leak）的元凶（上篇）（下篇）》，你會發現我通過相同的方式解決了事件注冊導致的內存泄露的問題。在這裏我在介紹另外一種有趣的應用。
在進行Windows Forms開發中，相信你會經常要求實現這樣的功能：如果點擊某個按鈕後，需要較長的反映時間，需要在點擊之後將Form的光標設置成沙漏的形狀（Wait Cursor），當整個處理結束後再將其回複。我們可以對EventHandlerWrapper的Invoke方法略加修改就能夠實現這個功能：
1: private void Invoke(object sender, EventArgs args)
2: {
3: if(null != Form.ActiveForm)
4: {
5: Form.ActiveForm.Cursor = Cursors.WaitCursor;
6: }
7: try
8: {
9: this.Method.Invoke(this.Target, new object[] { sender, args });
10: }
11: finally
12: {
13: if (null != Form.ActiveForm)
14: {
15: Form.ActiveForm.Cursor = Cursors.Default;
16: }
17: }
18: }
微信公眾賬號：大內老A
微博：www.weibo.com/artech
如果你想及時得到個人撰寫文章以及著作的消息推送，或者想看看個人推薦的技術資料，可以掃描左邊二維碼（或者長按識別二維碼）關注個人公眾號（原來公眾帳號蔣金楠的自媒體將會停用）。
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁麵明顯位置給出原文連接，否則保留追究法律責任的權利。
最後更新：2017-10-27 15:05:04