Tuesday, December 20, 2005
Why Do we need AppDomains ?
1- a place to load unload assemblies
3- security (assemblies inside same appdomain can have same policy)
Monday, December 12, 2005
A very powerful feature that has been taken for 6 years , now is back
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 :-)
Friday, December 09, 2005
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 .
Catch when Filter1() = True
Function Filter1() as boolean
throw new exception()
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
5- this is the trick . Filter1 is executed
6- B's Finally
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 .
Thursday, December 08, 2005
Throw THINGS that are not exceptions !!!
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 :
'call a naughty code that throws a non-exception
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
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
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