2

I have a thread that is very simple. The only thing the Thread object does is throw new Exception();. The reason why I did that is because I needed to test what happens if a exception happens in a separate thread in my application. I have tested this with a "real" run time exception and my problem is the same.

What I do before I call the thread is:

AppDomain.CurrentDomain.UnhandledException += CurrentDomainOnUnhandledException;
Application.Current.DispatcherUnhandledException += CurrentOnDispatcherUnhandledException;

//To handle exceptions in another thread
private void CurrentDomainOnUnhandledException(object sender, UnhandledExceptionEventArgs unhandledExceptionEventArgs)
{
    //Do nothing ignore exception
}

//To handle all exceptions in main thread
private static void CurrentOnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs dispatcherUnhandledExceptionEventArgs)
{
    dispatcherUnhandledExceptionEventArgs.Handled = true;
}

When this thread does throw a exception it first hits CurrentDomainOnUnhandledException like it should, and then it does not hit CurrentOnDispatcherUnhandledException. Right after CurrentDomainOnUnhandledException The stack then moves back to the Thread where it throws the exception and throws it again, executing the same line. It never stops doing this. It is basically a never ending loop and I can not figure out why.

The UnhandledExceptionEventArgs does not have a property to set, to say we have handled the exception and I am pretty sure this is part of the problem.

What am I doing wrong, how to I catch this UnhandledException in this thread, and let the thread continue to execute (preferred) or abort / kill the thread (not preferred) so that it does not continue to execute the throw new exception line.

I have tested this with debug and release (made sure debugging info on release was set to none) and this still happens in both versions, the exception continues to happen over and over again.

Thanks in advance, I am just stumped and have no idea why it does it.

leppie
  • 115,091
  • 17
  • 196
  • 297
Landin Martens
  • 3,283
  • 12
  • 43
  • 61
  • There is no possible way a thread can continue to execute after an uncaught exception. What code would it run? The whole point of throwing an exception is to specifically prevent the next line of code from executing. It's like trying to stay in the function after a `return` appears in the code. I don't know why you think you need to do this, but I'm pretty sure you're proceeding from a fundamental misunderstanding somewhere. – David Schwartz Sep 01 '12 at 05:25
  • Well, you got me convinced, no way to make this up. This would be a very serious CLR bug. Please document the .NET version you use and post the code that starts the thread and throws the exception so everybody can repro this on their own machine. – Hans Passant Sep 01 '12 at 10:28

1 Answers1

1

When this thread does throw a exception it first hits CurrentDomainOnUnhandledException like it should, and then it does not hit CurrentOnDispatcherUnhandledException. Right after CurrentDomainOnUnhandledException The stack then moves back to the Thread where it throws the exception and throws it again, executing the same line. It never stops doing this. It is basically a never ending loop and I can not figure out why.

You never handled the exception. You just returned back to the very same code that faulted in the first place. Say the code does this:

i = 1 / 0;
foo(i);

And say you catch the division by zero error, but in the handler, you do nothing but return. Well, what would you expect to happen? The code encountered a fatal error that makes further progress impossible and you did nothing to fix it. What value should i contain?!

Essentially, don't try to catch exceptions except as part of the design of the code that throws them. It just doesn't make sense, and whatever your outer problem is, there's probably a sensible way to do it.

But if a thread fails horribly, its process fails horribly. That's the nature of threads -- there's no isolation. Consider:

  1. Acquire lock
  2. Modify some object
  3. Release lock

What happens if the exception is thrown halfway through step 2? If your exception handler don't release the lock, the next thread to try to acquire it waits forever. If your exception handler does release the lock, the next thread to acquire it will access an object that's partially modified and perhaps in an inconsistent state. So an exception handler would have to make an intelligent decision, understand the code that threw the exception, as to what to do prior to releasing any locks held when the exception was thrown.

If you're going to catch the exception, you must figure out what the underlying problem is and repair it. In general, you can only do this if you fully understand the code that threw the exception. There's no generic way to do it because there's no generic way to repair a potentially corrupt object.

Ok, then how do I kill the thread in CurrentDomainOnUnhandledException so it stops looping the exception?

Generally that's not what you want to do. What if that thread holds locks? What if that thread allocated memory that it needs to release?

If you need this kind of isolation, use processes, not threads.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278