467,075 Members | 997 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,075 developers. It's quick & easy.

about AppDomain.UnhandledException

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?
Nov 17 '05 #1
  • viewed: 1722
Share:
5 Replies
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?

Nov 17 '05 #2
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).

"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?


Nov 17 '05 #3
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?


Nov 17 '05 #4
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?



Nov 17 '05 #5
thanks again.
"David Levine" <no******************@wi.rr.com> wrote in message
news:up**************@TK2MSFTNGP10.phx.gbl...
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?



Nov 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Marcio Izepe | last post: by
1 post views Thread by Kimmo Laine | last post: by
2 posts views Thread by guy | last post: by
9 posts views Thread by Gustaf | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.