VB.NET是怎样做到的（八）——On Error语句和When语句
2024-07-10 13:01:31
供稿：网友
感觉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对象记录异常。看来使用err也是语法甜头，性能苦头，凭空添加了这两句（幸好都不太复杂）。
接下来我编写了一个与此功能类似的函数，用的是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#中经常让开发者传参数传到吐血。
