Delegates and Events

Delegates and Events
Exception handling in IL is a big let down. We expected a significant amount of

complexity, but were proved wrong, right from the beginning. IL cannot be termed
as a machine level assembler. It actually has a number of directives like try and
catch, that work like their higher level counterparts.
a.cs
class zzz
{
public static void Main()
{
try
{
abc();
System.Console.WriteLine("Bye");
}
catch (System.Exception e)
{
System.Console.WriteLine("In Exception");
}
System.Console.WriteLine("After Exception");
}
public static void abc()
{
throw new System.Exception();
System.Console.WriteLine("abc");
}
}
a.il
.assembly mukhi {}
.class private auto ansi zzz extends [mscorlib]System.Object
{
.method public hidebysig static void vijay() il managed
{
.entrypoint
.locals (class [mscorlib]System.Exception V_0)
.try
{
call void zzz::abc()
ldstr "Bye"
call void [mscorlib]System.Console::WriteLine(class System.String)
leave.s IL_001e
}
catch [mscorlib]System.Exception
{
stloc.0
ldstr "In Exception"
leave.s IL_001e
}
IL_001e: ldstr "After Exception"
ret
}
.method public hidebysig static void abc() il managed
{
newobj instance void [mscorlib]System.Exception::.ctor()
throw
}
}
Output
In Exception
After Exception
In the above example, the function abc first creates an object that looks like
Exception using newobj and places it on the stack. Thereafter the throw instruction
throws an exception. This Exception is placed on the stack, hence the catch
instruction is called. In the catch instruction, e, a local varaible, is an instance of
Exception. The next instruction, leave.s jumps to label IL_001e, the label is beyond
the catch.
To exit off from a try or a catch block, instead of the branch instruction br, leave is
used. The reason is that we are dealing with exceptions, which are to be handled in
a special way in IL. Exception handling in IL is done using higher level instructions.
a.cs
class zzz
{
{
yyy a;
a=new yyy();
try
{
a.abc();
System.Console.WriteLine("Bye");
}
catch
{
System.Console.WriteLine("In Exception");
}
finally
{
System.Console.WriteLine("In finally");
}
}
}
class yyy
{
public void abc()
{
throw new System.Exception();
}
}
a.il
.assembly mukhi {}
{
{
.entrypoint
.locals (class yyy V_0)
newobj instance void yyy::.ctor()
stloc.0
.try
{
.try
{
ldloc.0
call instance void yyy::abc()
ldstr "Bye"
leave.s IL_0025
}
catch [mscorlib]System.Object
{
pop
leave.s IL_0025
}
IL_0025: leave.s IL_0032
}
finally
{
ldstr "In finally"
endfinally
}
IL_0032: ret
}
}
.class private auto ansi yyy extends [mscorlib]System.Object
{
.method public hidebysig instance void abc() il managed
{
throw
}
}
Output
In Exception
In finally
The above program has utilised a try catch without a parameter and a finally
clause. Adding a finally clause associates the same try with a catch, and a finally.
In a sense, two copies of try are created, one for catch and the other for finally.
If the catch directive is not supplied with an Exception object, it will take an object
that looks like System.Object. In the catch, the item is popped of the stack, as its
value holds no significance. The string is printed before the leave. Also, along with
try-catch is the finally clause which is the next to be executed. A finally is executed
as a separate try finally directive and it can only be exited using the endfinally
instruction.
a.il
.assembly mukhi {}
{
{
.entrypoint
.try
{
leave.s IL_0032
}
finally
{
ldstr "In finally"
endfinally
}
IL_0032: ret
}
}
Output
In finally
Nowhere is it specified that a try must have a catch. A finally will ultimately be
called at the end of the try.
a.il
.assembly mukhi {}
{
{
.entrypoint
ldstr "Bye"
ret
}
{
throw
}
}
Output
Exception occurred: System.Exception: An exception of type System.Exception
was thrown.
at zzz.vijay()
In the absence of a try catch block, if function abc throws an exception, it will not
get caught. Instead, a runtime error is generated. A try catch clause is
recommended to proactively catch the exception, otherwise when an exception is
thrown and the program will come to a grinding halt.
a.cs
public class zzz
{
{
int i = 1;
for ( i = 1; i<= 10 ; i++)
{
try
{
System.Console.WriteLine("1 try");
try
{
System.Console.WriteLine("2 try");
break;
}
finally
{
System.Console.WriteLine("2 finally");
}
}
finally
{
System.Console.WriteLine("1 finally");
}
}
System.Console.WriteLine(i);
}
}
a.il
.assembly mukhi {}
{
{
.entrypoint
.locals (int32 V_0)
ldc.i4.1
stloc.0
ldc.i4.1
stloc.0
br.s IL_0032
.try
{
IL_0006: ldstr "1 try"
.try
{
ldstr "2 try"
leave.s IL_0037
}
finally
{
ldstr "2 finally"
endfinally
}
}
finally
{
ldstr "1 finally"
endfinally
}
IL_0032: ldloc.0
ldc.i4.s 10
ble.s IL_0006
IL_0037: ldloc.0
call void [mscorlib]System.Console::WriteLine(int32)
ret
}
}
Output
1 try
2 try
2 finally
1 finally
1
The above program is quite lengthy, but very simple. It proves the fact that code
placed in a finally block is always executed. Like death and taxes, a finally cannot
be avoided.
The for statement branches to label IL_0032 where we first check for the value to
be less than or equalto10. If it results in TRUE, the code at label IL_0006 is
executed. A we learnt in one of the earlier chapters, the condition check for the for
statement is always placed at the bottom in IL.
In the first attempt, string "1 try" is printed . Thereafter the code within the second
try is executed, where "2 try" is printed. The break statement in C# gets converted
to a leave to label IL_0037 in IL. This label signifies the end of the for statement.
The leave instruction is smart enough to realize that it is located within two trys
with a finally clause, hence it calls the code with the finally instruction.
Under normal circumstances, break becomes a branch instruction if not placed
within try-catch.
a.cs
public class zzz
{
public void abc()
{
lock(this)
{
}
}
{
}
}
a.il
.assembly mukhi {}
{
.method public hidebysig static void vijay() il managed {
.entrypoint
ret
}
{
.locals (class zzz V_0)
ldarg.0
dup
stloc.0
call void [mscorlib]System.Threading.Monitor::Enter(class System.Object)
.try
{
leave.s IL_0011
}
finally
{
ldloc.0
call void [mscorlib]System.Threading.Monitor::Exit(class System.Object)
endfinally
}
IL_0011: ret
}
}
The lock keyword ensures that while one thread executes a function, the other
threads remain suspended. This keyword gets translated into a large amount of IL
code. In fact, it generates the maximum amount of code amongst all the keywords.
The C# compiler first calls the static function Enter from the Monitor class. Then, it
executes the code located in a try. The try block here contains no code. On
encountering the leave instruction, the program enters the finally which calls the
Exit function from the Monitor class. This initiates another thread that is waiting
at the Enter function.
Whenever an exception occurs, an object representing the exception must be
created. This exception object has to be a class derived from Exception and cannot
be a value type or a pointer.
A Structured Exception Handling (SEH) block is made up of a try and one or more
handlers. A try directive is used to declare a protected block.
a.il
.assembly mukhi {}
{
{
.entrypoint
.try
{
ret
}
{
stloc.0
leave.s IL_001e
}
ret
}
}
We cannot exit from a protected block with a ret but, on using it, no errors are
generated at assemble time or run time. As a rule, only a leave or a throw to
another exception is acceptable to exit from a protected block. A leave statement is
permitted in the try and not in the catch.
a.il
.assembly mukhi {}
{
.entrypoint
.try
{
ldstr "Bye"
.try
{
call void zzz::pqr()
ldstr "Bye1"
leave aa1
}
{
stloc.0
ldstr "In Exception1"
leave.s IL_001e
}
aa1: leave.s IL_001e
}
{
stloc.0
leave.s IL_001e
}
ret
}
{
ret
}
.method public hidebysig static void pqr() il managed
{
throw
}
}
Output
Bye
In Exception1
After Exception
We can nest as many trys or protected blocks within each other. A leave is required
at the end of every try to avoid all errors.
We can have four types of handlers for a try or a protected block. They are:
• finally
• catch
• fault
• filter
Only one of it can be used at a time.
a.il
.assembly mukhi {}
{
.entrypoint
.try
{
ldstr "Bye"
leave.s IL_001e
}
{
stloc.0
leave.s IL_001e
}
finally
{
ldstr "In finally"
endfinally
}
ret
}
{
throw
}
}
Output
In Exception
After Exception
If we comment out the code where the function abc has been called, we get the
following output:
Output
Bye
In finally
After Exception
As mentioned earlier, the protected block can only be handled by a single handler.
In the above example, when an exception is thrown, the catch is called and not
finally as it does not have its own try directive. The runtime does not give us any
error, but it ignores the finally handler.
If, however, no exception is thrown, as is the case when we comment out the call of
the function abc, then the finally gets called.
It is quaint that the try is a directive, but the handler is not. We have two classes of
handlers:
• exception resolving handlers

• exception observing handlers.
The finally and fault handlers are exception observing handlers as they do not
resolve the exception.
In an exception resolving handler, we try and resolve the exception so that normal
program control continues. The catch and filter handlers are examples of such
handlers.
The deepest handler will be visited first, followed by the next enclosing one and so
on, until we find an appropriate handler. A handler has its own instructions, using
which, the program can exit a handler. It is illegal to use any other instruction for
this purpose, but at times the assembler is unable to detect this misfit.
a.il
.assembly mukhi {}
{
{
.entrypoint
.try
{
}
{
br a1
}
ret
}
.method public hidebysig static void pqr() il managed
{
a1:
ret
}
}
Error
***** FAILURE *****
We are not allowed to jump off a catch handler. It is essential to leave the handler
in an orderly manner only.
a.il
.assembly mukhi {}
{
{
.entrypoint
.locals (class zzz V_0)
newobj instance void zzz::.ctor()
stloc.0
startTry:
ldstr "in try"
call void System.Console::WriteLine(class System.String)
//call instance void zzz::abc()
ldstr "after function call"
leave exitSEH
endTry:
startFault:
ldstr "in fault"
endfault
endFault:
.try startTry to endTry fault handler startFault to endFault
exitSEH:
ldstr "over"
ret
}
{
throw
}
}
Output
in try
after function call
over
If we comment out the call of the function abc, we get an error, a Windows error,
which is incomprehensible. The purpose of the above program is to demonstrate
that we can use labels to delimit code in a protected block. Thereafter, we can use
the try directive, indicating to it the start and end label of our code and also the
start and end of the fault handler. This is another way of utilising the try directive.
The catch keyword creates a type filtered exception. Whenever an exception occurs
in a protected block, the EE checks whether the exception that occurred earlier, is
equal to or a sub-type of the error that the catch expects. If the type matches, the
code of the catch is called. If the type does not match, the EE will continue to
search for another handler.
a.il
.assembly mukhi {}
{
{
.entrypoint
.try
{
a1:
ldstr "Bye"
leave.s IL_001e
}
{
stloc.0
leave.s a1
}
ret
}
{
throw
}
}
Output
In Exception
Bye
After Exception
The program is not allowed to resume execution after an exception occurs. This
means that, we cannot go back to the protected block where the exception took
place. In this case, we are allowed to do so, but keep in mind that we were using a
beta copy of the assembler.
Whenever the EE sees a leave in a catch block, it knows that the exception is done
with, and the system returns to a normal state.
a.il
.assembly mukhi {}
{
{
.entrypoint
.try
{
ldstr "Bye"
leave.s IL_001e
}
{
stloc.0
rethrow
}
ret
}
{
throw
}
}
Output
In Exception
was thrown.
at zzz.vijay()
Here, at the end of the catch is the rethrow instruction, which rethrows the same
exception again. As there is no other catch block to catch the exception, the
exception is thrown at run time.
a.il
.assembly mukhi {}
{
{
.entrypoint
.try
{
.try
{
ldstr "Bye"
leave.s IL_001e
}
{
stloc.0
rethrow
}
}
{
stloc.0
}
ret
}
{
throw
}
}
Output
In Exception
In Exception1
After Exception
Here, we placed another try directive with a separate catch. The exception that is
thrown by the inner catch, cannot be caught by another catch at the same level. It
needs to be caught by the catch at the higher level. Thus one more catch is needed.
a.il
.assembly mukhi {}
{
{
.entrypoint
.try
{
ldstr "Bye"
leave.s IL_001e
}
{
stloc.0
leave.s IL_001e
}
catch [mscorlib]System.IOException
{
stloc.0
leave.s IL_001e
}
ret
}
{
newobj instance void [mscorlib]System.IOException::.ctor()
throw
}
}
Output
In Exception
After Exception
The C# compiler watches our code like a hawk. On the other hand, the assembler is
a blind bat.
There are two exception handlers:
• IOException: This handles Input/Output Exceptions.

• Exception: This is a generic handler that handles generic exceptions
since all exceptions are derived from exception.
Consciously, we have placed the generic Exception handler first. Therefore,

irrespective of the exception thrown, the second handler will never get called. The
function abc now throws a IOException. The generic Exception handler, which is
placed earlier in the code, is encountered first, and therefore, it deals with the
exception. The C# compiler would have generated an error in this situation, but the
assembler assumes what you are conscious of your deeds.
Output
Exception occurred: System.ExecutionEngineException: An exception of type
System.ExecutionEngineException was thrown.
at zzz.vijay()
The above exception is thrown when there is no leave in a catch and there is
another catch following this one. In one of our earlier programs above, we have
used only a single catch.
a.il
.assembly mukhi {}
{
.method public static void vijay()
{
.entrypoint
ldstr "start"
br start
a2:
ldstr "in a2"
pop
ldc.i4.0
endfilter
start:
.try
{
ldstr "in try"
ldstr "after function call"
leave a1
}
filter a2
{
ldstr "filter"
pop
leave a1
}
a1:
ret
}
{
throw
}
}
Output
start
in try
was thrown.
at zzz.vijay()
The last type of fault handler, which is the most generic, either does not seem to
work or it could also mean that we have done something wrong.
We use the keyword filter with a label, which denotes the start point of some code.
This code checks whether the exception must be handled or not. This is triggered
off by placing either the number 0 or 1 on the stack. In our case, none of the code
dealing with the filter gets called.

Delegates and Events

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Delegates and Events

Hochgeladen von

Copyright:

Verfügbare Formate

Delegates and Events

Exception handling in IL is a big let down. We expected a significant amount of

Only one of it can be used at a time.

• exception resolving handlers

There are two exception handlers:

• IOException: This handles Input/Output Exceptions.

Consciously, we have placed the generic Exception handler first. Therefore,

Das könnte Ihnen auch gefallen