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/Ex...Exception.aspx http://blogs.msdn.com/cbrumme/archiv.../01/51524.aspx
The CLI specifications also have a good description of the .NET model.
"John Richardson" <j3**********@hotmail.com> wrote in message
news:Or*************@TK2MSFTNGP15.phx.gbl...
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" <no******************@wi.rr.com> wrote in message
news:uA**************@TK2MSFTNGP09.phx.gbl... 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" <j3**********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... 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?
