感覺VB.NET特有的功能快要被我研究完了，那么這個系列也快要終止了，不知道能不能湊足10篇。

本次討論的是異常處理語句。VB.NET推薦使用Try...End Try塊來進行結構化的異常處理，但是為了確保兼容性，它也從以前版本的BASIC中借鑒了On Error語句。其實On Error并不能算是VB的優點，因為使用它會破壞程序的結構，讓帶有異常處理的程序難以看懂和調試。但是我一直很驚嘆于VB的工程師是怎樣實現它的，因為On Error可以讓異常的跳轉變得很靈活，不像Try那樣受到限制。首先看看Try是怎樣實現的：

Public Function F1() As Integer
Try
Dim n As Integer = 2 \ n
Catch ex As Exception
MsgBox(ex.Message)
End Try
End Function

這是最簡單的異常處理程序，通過Reflector反匯編（如果用ILDasm，不要選擇“展開try-catch”），可以發現整個過程被翻譯成19條指令。留意這一句：

.try L_0000 to L_0006 catch Exception L_0006 to L_0022

這就是典型的try塊，在catch處直接指定要捕獲的異常，然后指定catch區的位置，非常清晰。還要留意這兩句：

L_0007: call ProjectData.SetProjectError

L_001b: call ProjectData.ClearProjectError

可以看出，這兩句是在catch塊的開頭和末尾。深入這兩個過程我發現它是在為Err對象記錄異常�？磥硎褂肊rr也是語法甜頭，性能苦頭，憑空添加了這兩句（幸好都不太復雜）。

接下來我編寫了一個與此功能類似的函數，用的是On語句處理異常：

Public Function F2() As Integer
On Error GoTo CATCHBLOCK
Dim n As Integer = 2 \ n
Exit Function
CATCHBLOCK:

MsgBox(Err.Description)

End Function

這不比上一個過程復雜，但是反匯編以后，它的IL代碼竟然有47條指令，剛才才19條��！最主要的改變是try部分，現在它是這樣：

.try L_0000 to L_0022 filter L_0022 L_0036 to L_0060

注意，catch不見了，而出現了filter。我從沒在C#生成的IL中見過filter。由于try和filter不屬于IL，而是屬于元數據，所以我查詢了Meta Data一節的文檔，filter大概能夠進行一些過濾，滿足一定條件才進入處理異常的塊中，本例來說，L_0022指令開始就是過濾器，它是：

L_0022: isinst Exception
L_0027: brfalse.s L_0033
L_0029: ldloc.s V_4
L_002b: brfalse.s L_0033
L_002d: ldloc.3
L_002e: brtrue.s L_0033
L_0030: ldc.i4.1
L_0031: br.s L_0034
L_0033: ldc.i4.0
L_0034: endfilter

endfilter就是異常處理部分代碼的開始。而L0030之前的代碼是過濾器的判斷部分，V_4是VB自己加入保存錯誤代碼的變量。在整個反匯編中，我發現設計成處理異常部分的代碼在IL里其實也是在try塊中，也就是說程序的結構已經不是規整的try...catch塊，產生異常的語句和處理異常的語句在一起，而真正處理異常的指令是一大堆繁冗拖沓的跳轉語句。

下面看看我編寫的第三個例子：

Public Function F3() As Integer
On Error Resume Next
Dim n As Integer = 2 \ n
End Function

這個值有2行的過程動用了VB強大的語法殺手——On Error Resume Next，它將忽略所有異常，讓代碼緊接產生異常的語句繼續執行下去，猜猜這個功能產生了多少IL指令？答案是50條！比普通的On Error還要長。其實現我就不多說了，和前面的On語句差不多。不過50這個數字似乎提醒了大家，不要在程序里偷懶使用On Error處理異常，這樣產生的代價是不可接受的。

最后一個例子是VB.NET的When語句，它可以實現對Catch部分的過濾：

Public Function F1() As Integer
Dim n As Integer = 0
Try
Dim m As Integer = 2 \ n
Catch ex As Exception When n = 0
MsgBox(ex.Message)
End Try
End Function

里面的When語句進行了對變量n的判斷，僅當n = 0的時候才進入處理部分。聽到“過濾”兩個字，我們已經猜出，它是用try...filter來實現的。沒錯。這里的filter主要是進行ex是否是Exception型，n是否等于零等，當過濾成功，就會轉移到異常處理段進行處理。這次VB生成的代碼要比On Error語句規則得多，結構相當清晰。

本次我們還借助On Error語句和When語句了解到try filter結構，它是C#不能生成的，因此，我發現它不能被常見的反編譯器反編譯（因為反編譯器的編寫者只知道C#，呵呵）。而且用了On Error后程序結構變得異常混亂，這在產生負面作用的時候，是不是能夠變相起到保護我們代碼的作用呢？


End Sub

如果只想指定k，讓i和j使用默認值，就可以使用按名傳遞，如下

TestOptional(k := 2)

而且這種方式不受參數表順序的限制

TestOptional(k := 2, i := 3, j := 5)

這些的確是相當方便的功能，C#就不支持上述兩個特性。我們看看它是怎樣在IL級別實現的。上述第一個方法在IL中的定義為

.method public instance void TestOptional([opt] int32 i) cil managed
{
.param [1] = int32(0x00000001)
.maxstack 8

可見，參數被加上了[opt]修飾符，而且.param指定了參數的默認值。這是只有VB能識別的內容，C#會跳過他們。在調用的時候，VB若發現參數被省略，則自動讀取.param部分的默認值，并顯式傳遞給過程。這一部分完全由編譯器處理，而且沒有任何性能損失，和手工傳遞所有參數是完全一樣的。至于按名傳遞，VB會自動調整參數的順序，其結果與傳統方式的傳遞也沒有任何的不同。這說明我們可以放心地使用這項便利。而且帶有可選參數的過程拿到C#中，頂多變成不可選參數，也不會造成什么其他的麻煩。

PS.很多COM組件都使用了默認參數，而且有些過程的參數列表非常長，在VB里可以輕松地處理它們，而在C#中經常讓開發者傳參數傳到吐血。