.NET ShortCut

1- a place to load unload assemblies
2- isolation
3- security (assemblies inside same appdomain can have same policy)
4- configuration

# posted by test2512 @ 2:44 PM 0 comments

VB DTEE ...............
Yes it is back , I cannot believe that . I deadly needed this feature in
2002 and 2003. and I always wanted to see the one in charge who has removed
this feature , but fortunately now I wont be searching for him any more :)

Now (in 2005) I can open the immediate window without running the program at
all and execute commands .without running my program I can invoke a function
, evaluate an expression , create an object , anything !!!!!!
Wow awseome :-)

# posted by test2512 @ 2:53 AM 0 comments

Some languages like VB.NET but not C# supports Exception Filters .

Let's take these quick scenarios :

1- procedure A which has an exception handler is calling Proc B which
doesn't have an exception handler. Proc B Throw an exception . What happens
? Of course the runtime will search the stack for any catch until it hits A.
so A cacth the exception

2- same as before but B has an exception handler . What happens ? Of course
B catch the exception which might in turn voluntarily throw the exception .

3-
Sub A
Try
B()
Catch when Filter1() = True
DoSomething()
End Try
End sub

Function Filter1() as boolean
return True
End function

Sub B
Try
DoWork()
Finally
FinalizeMyWork()
End Try
End sub

Sub DoWork()
throw new exception()
End sub

The question now is : what are the ordered steps of execution ?
1- A calls B
2- B calls DoWork()
3- DoWork throw an exception
4- CLR will search in the stack for a handler until it finds A's
Handler
5- this is the trick . Filter1 is executed
6- B's Finally
7- DoSomething

So here is the lesson : TAKE CARE , some code could run after the try and
before the Finally . In our case , from B's Perspective , DoWork() is
executed then (SHOULD) followed by FinalizeMyWork(). But in practical , NO the
filter is executed in between . For me it is like (not is) code injection .

# posted by test2512 @ 11:24 PM 0 comments

This is my first time to know that we can throw types that are not
exceptions (not derived from system.exception)
Fortunately this cannot be done directly from CLS compliant languages like
C# and VB , but what if we are calling method M1() written by naughty C++ or
IL which throws an integer for example (throw 4). How can we catch this in
C# or VB ?

In .NET v1.x we can write :

Try
'call a naughty code that throws a non-exception
Catch

End try

This approach has 2 issues :
1- there is no variable for catching the exception
2- non-system exceptions are not accumulated on the stack trace so we cannot
debug .

In .NET v2.0 :

Non-system exceptions are wrapped up with
System.Runtime.CompilerServices.RuntimeWrappedException which derives from
System.Exception . And even more there is a switch to enable or disable this
: <Assembly:
System.Runtime.CompilerServices.RuntimeCompatibilityAttribute(true)>

CLR Magic :

If assembly A (written in IL) throws a non-system exception . Assembly B
(written in C#) calls A . Assembly C (written in C++) call B.
1- if A catch it . It will see the non-system exception and never see that
it has been wrapped
2- if B catch it . It will see RuntimeWrappedException
3- if C catch it . It will see the non-system exception and never see that
it has been wrapped

# posted by test2512 @ 6:27 PM 0 comments