Re: Why finally?

Yes, very nice. I get the same results from executing the code as well.
This seems to be a definite improvement of V1.x of the framework.

I did make a minor adjustment inside the try block of threadproc to throw an
exception. I did this to test to see if the finally block would hold for
normal exception paths (and to see if I could break the guarantee as well).
//inject an exception
for (int i = 0; i < 2; i++)
i = i % i;


After displaying the exception in a dialog box, it did fire the finally
block to release the resource.


--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
news:usqTkHUYGHA.4864@xxxxxxxxxxxxxxxxxxxxxxx
By 'asynchronous' I mean that the exception is not initiated by an
explicit
call to 'throw' in the executing code path (a thread).
Rather, it results from a memory allocation fault (OOM) or an injected
failure like Abort that can happen on any instruction in another thread
(or
threads see: OOM). I don't consider StackOverFlow to be asynchronous, a
StackOverflow can't be injected in another thread. Note also that I'm not
talking about CER in V2 either, I'm just talking about a feature of the
CLR,
that guarantees that the finally block will execute in the presence of an
asynchronous exception (Abort, OOM).

To see what I mean, consider this simple case, where an Abort is injected
in
another thread:

class Tester
{
static void Main()
{
Thread t = new Thread(new ThreadStart(ThreadProc));
t.Start();
Thread.Sleep(150);
// Inject an asynchronous ThreadAbortException in the target thread,
// The choice of the sleep times guarantees that the exception occurs
while
executing the finally backout code
t.Abort();
Console.WriteLine("Target Thread aborted");
}

static void ThreadProc()
{
IntPtr somePtr = IntPtr.Zero;;
try
{
somePtr = Marshal.AllocHGlobal(2000000);
Thread.Sleep(100);
}
finally
{
Thread.Sleep(200);
Marshal.FreeHGlobal(somePtr);
Console.WriteLine("Resource freed");
}
}
}
}

When running this on V2 of the framework, the CLR will prevent the
asynchronous abort (ThreadAbort or OOM) to be injected while running the
finally block. This means that the allocated resource will be freed
despite
the presence of an asychronous exception.
However, when you run this code on V1.X, the finally will not run to an
end
and the resource will leak.

Willy.



"Alvin Bruney" <www.lulu.com/owc> wrote in message
news:%23Zl6$JOYGHA.3496@xxxxxxxxxxxxxxxxxxxxxxx
| That guarantee needs qualifications right? A finally block is not
expected
| to execute when the CLR throws a stack exception or an execution engine
| exception. I take it that these form part of the qualification to the
| *guarantee
|
| --
| ________________________
| Warm regards,
| Alvin Bruney [MVP ASP.NET]
|
| [Shameless Author plug]
| The O.W.C. Black Book with .NET
| www.lulu.com/owc, Amazon
| Professional VSTO.NET - Wrox/Wiley 2006
| -------------------------------------------------------
|
| "Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
| news:%23688MEMYGHA.128@xxxxxxxxxxxxxxxxxxxxxxx
| >
| > "Jon Davis" <jon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
| > news:uuTSmZFYGHA.3972@xxxxxxxxxxxxxxxxxxxxxxx
| > |I understand that the finally sub-block will execute regardless of
| > whether
| > | try succeeded or not. But so will code that follows try...catch. So
| > then
| > | what is the difference between ...
| > |
| > | try {
| > | do.something.that.breaks();
| > | } catch {
| > | do.something.that.works();
| > | }
| > | cleanup();
| > |
| > |
| > | .. and ..
| > |
| > | try {
| > | do.something.that.breaks();
| > | } catch {
| > | do.something.that.works();
| > | } finally {
| > | cleanup();
| > | }
| > |
| > | .. other than organizational aesthetics ??
| > |
| > | Thanks,
| > | Jon
| > |
| > |
| >
| > In V2 of the framework, the finally block is guaranteed to run to
| > completion, even in the presence of an asynchronous exception (think
| > ThreadAbortExceptions).
| >
| > Willy.
| >
| >
|
|




.

Relevant Pages

  • Re: Structured Exception Handling (was: Try Finally...)
    ... >statements will be traversed outwards exactly once, executing each ... What really bite me is the re-raise of the exception ... and the continuation in statementList2. ... This means that during unwinding the code immediately returns, ...
    (comp.lang.pascal.delphi.misc)
  • Re: DirectShow Insanity
    ... The exception happens immediately upon executing the ... > and what exactly is shown in the debug output window? ... > what happens if you wait for completion befor exiting the program? ...
    (microsoft.public.win32.programmer.directx.audio)
  • Re: WebRequest problems
    ... > I now close the stream as well as the response, ... And are you always executing that Close? ... could be throwing an exception. ... the problem is that there's a connection pool and if the responses ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: HasRows() vs. Read() and ERROR suppression
    ... > record found by executing the commandText. ... >> Syntax error converting datetime from character string. ... >> on the Command object, ... >> MUST call .Readon the SqlDataReader, or you don't get the exception. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: looking for asynchronous flow execution framework
    ... the executing thread wait for a long period. ... I doubt if there's any general-purpose framework that will do ... your AiroplaneLifecycle object would expose ... methods that the framework would call in response to external events. ...
    (comp.lang.java.programmer)