Vb. NET is how to do (eight)--on error statements and when statements

error| statement feeling vb.net unique function is about to be my research finished, then this series is also about to terminate, do not know can make up 10 pieces.

This is a discussion of exception handling statements. Vb. NET recommended to use Try ... End Try block for structured exception handling, but in order to ensure compatibility, it also borrows the On Error statement from the previous version of Basic. In fact, on error is not the advantages of VB, because the use of it will destroy the structure of the program, so that with exception handling procedures difficult to understand and debug. But I have always been amazed at how VB engineers implement it, because on error allows abnormal jumps to change very flexibly, not as limited as try. First look at how the try is implemented:

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

This is the simplest exception handler, through the reflector disassembly (if you use ILDASM, do not choose "expand Try-catch"), you can find that the whole process is translated into 19 instructions. Pay attention to this sentence:

. Try l_0000 to l_0006 catch Exception l_0006 to l_0022

This is the typical try block, specifying the exception to catch directly at the catch, and then specifying the location of the catch area, very clear. Also pay attention to these two sentences:

L_0007:call Projectdata.setprojecterror

L_001b:call Projectdata.clearprojecterror

As you can see, these two sentences are at the beginning and end of the catch block. In both of these processes I found that it was logging an exception for the Err object. It seems to use err is also a grammatical sweetness, the performance of the pain, added these two lines (fortunately not too complicated).

Next I wrote a function similar to this one, with an on statement to handle the exception:

Public Function F2 () as Integer
On Error GoTo Catchblock
Dim N as Integer = 2 \ n
Exit Function
Catchblock:

MsgBox (Err.Description)

End Function

This is not more complicated than the previous process, but after disassembly, its IL code unexpectedly has 47 instructions, just 19! The main change is the try part, now it's like this:

. Try l_0000 to l_0022 filter l_0022 l_0036 to l_0060

Notice that the catch is gone and the filter appears. I have never seen filter in the IL generated by C #. Since try and filter do not belong to IL, but are metadata, so I queried the Meta data section of the document, filter can probably do some filtering, meet certain conditions before entering the processing of the exception block, in this case, the l_0022 instruction began is the filter, it is:

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 is the beginning of the exception handling part of the code. and L0030 before the code is the filter part of the decision, V_4 is VB to add its own to save the error code variables. In the entire disassembly, I found that the code designed to handle the anomaly is actually in the try block in IL, which means that the structure of the program is not a regular try...catch block, resulting in an exception to the statement and handling the exception of the statement, and the real deal with the exception of the instructions is a lot of cumbersome to procrastinate jump statements.

Let's look at the third example I've written:

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

This value has 2 lines of the process using the VB powerful syntax killer--on Error Resume Next, it will ignore all exceptions, so that the code immediately generated the exception of the statement to continue, guess how many of the function generated IL instructions? The answer is 50! Longer than the normal on error. I don't say much about it, just like the previous on statement. But the number 50 seems to remind you not to use the On error to handle exceptions in your program, which is unacceptable.

The last example is the vb.net when statement, which enables filtering of the catch part:

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

The When statement inside the decision to the variable n, only when n = 0 to enter the processing section. Hear "filter" two words, we have guessed, it is to use try...filter to achieve. That's right. Here the filter is mainly to whether ex is exception type, n is equal to zero, when the filter succeeds, it will be transferred to the exception processing segment for processing. VB generated by the code than on the error statement more rules, the structure is quite clear.

This time we also use the On Error statement and the When statement to understand the try filter structure, which is C # can not be generated, so I found that it can not be the common anti-compiler decompile (because the compiler's creator only know C #, hehe). And with the On error after the program structure becomes extremely chaotic, this in the negative effect, is it possible to disguise the role of protecting our code?


End Sub

If you want to specify K only, let I and J use the default values, you can use the by name pass, as follows

Testoptional (k: = 2)

And this way is not limited by the order of parameter tables

Testoptional (k: = 2, I: = 3, J: = 5)

These are indeed quite handy features, and C # does not support both of these features. Let's see how it is implemented at the IL level. The first method described above is defined in the IL as

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

Visible, the parameter is added with the [opt] modifier, and. PARAM specifies the default value for the parameter. This is only VB can recognize the content, C # will skip them. When a call is made, VB automatically reads the default value of the. param part and passes it explicitly to the procedure if it finds that the parameter is omitted. This part is entirely handled by the compiler and has no performance penalty, and is exactly the same as passing all parameters manually. As for the transfer by name, VB will automatically adjust the order of parameters, the results and the traditional way of transmission is not any different. This means that we can safely use this convenience. And with optional parameters of the process to get C #, the most becomes an optional parameter, also does not cause any other trouble.

PS. Many COM components use the default parameters, and some procedures have a very long list of parameters, in VB can easily handle them, and in C # often allow developers to pass the parameters to vomit blood.