about AppDomain.UnhandledException

[John Richardson]

Quick question about the UnhandledException event and associated Handler.

I just implemented this handler for the first time, and am surprised that it
this event is being raised for an exception that I have handled.
I have the following:

private void Load()
{
try
{
Load(true);
}
catch (ThreadAbortException ex)
{
Debug.WriteLine("Thread Abort Exception!!!");
/* Empty Catch should eat the exception? */
}
catch (Exception ex)
{
throw;
}
}

but each time I get a ThreadAbortException, my UnhandledException handler is
being fired from this method. Why and what do I have to do to prevent this
behaviour?

 

[David Levine]

ThreadAborts are special exceptions...even though they are caught in the
catch handler, when the code exits that catch handler the runtime rethrows
the exception until either the abort has been explicitly reset
(Thread.ResetAbort) or until the thread has unwound to the top of the stack
(TOS) and the thread has been terminated.

If you do not want to get the UE event then you must reset the abort within
the catch handler for the ThreadAbort exception. If you put the
Thread.ResetAbort anywhere after that (such as a finally block) you will
still get the UE notification. This is because the catch handlers are
evaluated all the way up the stack until it reaches TOS. If it has not found
a suitable catch handler by then you immediately get the UE event. It then
goes back and executes finally blocks, so if you put the reset in a finally
block the reset will occur after the UE event was fired.

The behavior of the abort is fairly well documented even if the timing is
not obvious.

 

[John Richardson]

thanks for the detailed response. I was a bit confused by this. This is my
first forray into threading with C# as well... I should have read more
before using them (threads).

 

[John Richardson]

I've seen your name around a couple of threading related posts. Do you know
a good online/hard copy reference I might read to understand the subtleties?
I'm not 100% about the theory nor implementation about threading nor how
synchronization works in C#. I'd like to know more about best practices.

 

[David Levine]

That's a very broad topic. C#/.NET simplifies some of it, but for a real
understanding of how threading, synchronization, and exceptions work you
really need to understand how these work under Win32, since .NET is layered
on top of that, and many of the concepts are the same.

For base threading and synchronization, the books by Richter are a great
place to start.

Exceptions are built on top of the Windows Structured Exception Handling
(SEH) mechanism. Richter does a pretty good job of describing this too.
Exceptions are also integral to issues such as reliability, finalization,
finalizers, deterministic finalization, etc., since these are impacted by
SEH and exceptions.

Unfortunately, there is no single source you can go to for a complete
discussion of exceptions under .NET - pieces of it are scattered all over.

For information on best practices and strategies it is even less
satisfactory - MSFT and others have published guidelines, but I don't agree
with all the recommendations.

These links have good information on the basics of how the mechanism works,
both fot win32 and for .net.

http://www.microsoft.com/msj/0197/Exception/Exception.aspx
http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx

The CLI specifications also have a good description of the .NET model.

 

[John Richardson]

thanks again.

That's a very broad topic. C#/.NET simplifies some of it, but for a real
understanding of how threading, synchronization, and exceptions work you
really need to understand how these work under Win32, since .NET is
layered on top of that, and many of the concepts are the same.

For base threading and synchronization, the books by Richter are a great
place to start.

Exceptions are built on top of the Windows Structured Exception Handling
(SEH) mechanism. Richter does a pretty good job of describing this too.
Exceptions are also integral to issues such as reliability, finalization,
finalizers, deterministic finalization, etc., since these are impacted by
SEH and exceptions.

Unfortunately, there is no single source you can go to for a complete
discussion of exceptions under .NET - pieces of it are scattered all over.

For information on best practices and strategies it is even less
satisfactory - MSFT and others have published guidelines, but I don't
agree with all the recommendations.

These links have good information on the basics of how the mechanism
works, both fot win32 and for .net.

http://www.microsoft.com/msj/0197/Exception/Exception.aspx
http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx

The CLI specifications also have a good description of the .NET model.