1

I have this code:

001 private void uiButton1_Click(object sender, EventArgs e)
002 {
003     string someString = "";
004     try
005     {
006         someString = ThisMethodThrowsAnException();
007     }
008     catch (Exception)
009     {        
010         throw;
011     }
012 }

The code does get to the "throw" in the catch but the standard winforms "unhandled exception" dialog never shows up.

ThisMethodThrowsAnException() is throwing an exception of type System.Exception. I have an event attached to Application.ThreadException. That event is not being hit in this case. uiButton is a standard winforms button. I created a button that throws an exception in its event handler and that exception is being caught by Application_ThreadException. All of the processing is happening on one thread.

For the life of me I can't see why this code wouldn't result in the normal exception box (which, since this is an app that only I use, is something that's helpful). There are other places in this app where I've seen the standard exception dialog.

I have a button click handler that looks like this:

 private void button2_Click(object sender, EventArgs e)
    {
        throw new Exception("I are broke!"); 
    }

And a ThreadException handler that looks like this:

 static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
        {
            MessageBox.Show("Exception: " + e.Exception.Message); 
        }

I'm using UnhandledExceptionMode.Automatic. When I click the uiButton1 I do not get an exception message via Application_ThreadException. However if I add a throw new Exception just before the method call to ThisMethodThrowsAnException, I do get the MessageBox.

I do get a MessageBox via button2 (through Application_ThreadException).

So something is happening in ThisMethodThrowsAnException. The only thing I can think of is that it's starting up a new thread, but that's not the case when I debug through it.

If the exception was happening on a different thread would it get back to the catch block in uiButton1_Click?

jcollum
  • 43,623
  • 55
  • 191
  • 321
  • 1
    @Slaks: I don't understand. The type is given. The message seems irrelevant. – jcollum Jan 13 '10 at 22:21
  • 1
    What happens if you remove the try/catch? Just trying to see if that helps u understand what's going on... – psychotik Jan 13 '10 at 22:23
  • @psychotik: same result. I added the try catch to see if it was being swallowed somewhere and only caught while running in debug. That wasn't the case. – jcollum Jan 13 '10 at 22:24
  • What UnhandledExceptionMode is configured for your application? – Andrii Shvydkyi Jan 13 '10 at 22:28
  • I've deleted my answer - because it wasn't answer, but another question: Out of interest - I spotted http://stackoverflow.com/questions/347502/why-does-the-inner-exception-reach-the-threadexception-handler-and-not-the-actual/348115#348115 on the related list and wonder if there's a correlation. Throw an exception with an inner exception from this inner method and see if it actually works as expected? If there's a relation, the exception that escapes should be the inner one, not the outer one. Hope that makes sense. – Andras Zoltan Jan 13 '10 at 22:31
  • This works like a champ for me. I'm using UnhandledExceptionMode.CatchException. *shrug* – John Kraft Jan 13 '10 at 22:37
  • @Andrey: Well I never explicitly set it. I fixed the underlying issue and I'm now trying to get it back to a state that throws an exception :) to see if changing exception mode helps. – jcollum Jan 13 '10 at 22:39
  • @Andras: could be related, but I'm not doing anything like that. And reading that post made my head hurt... I'll investigate the code I'm calling and see if it's doing anything untoward. Still, I'm pretty sure (as stated) that all this code is happening in one thread. – jcollum Jan 13 '10 at 22:41
  • +1 - I'm so glad to have found this question and answer - I've been tearing my hair out with the same problem today. – GarethOwen Jul 07 '11 at 14:46

1 Answers1

3

The debugger is getting in the way. The Application class is aware that a debugger is attached to the program, it uses System.Diagnostics.Debugger.IsAttached(). If that's the case, it does not use a try/catch block around the message loop and the Application.ThreadException event will not run.

This is quite intentional. If the catch block were active, you would have a very hard time troubleshooting exceptions in your program. Without the catch block, the debugger will always stop and show you what is wrong.

You can reproduce the runtime behavior. Add this line of code to your Main() method before the Run() call:

 Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Ahh, but nowhere did I say that I only saw this behavior while a debugger was attached. I tried all three app exception modes. The results: two gave me no exception dialog and the third closed my app ("MyApp has encountered a problem and needs to close.") – jcollum Jan 13 '10 at 23:14
  • To clarify: while running the app without the debugger, the uiButton1_Click simply does nothing. While running with the debugger the debugger stops on line 10. – jcollum Jan 13 '10 at 23:16
  • Your ThreadException event handler appears to be gobbling exceptions without reporting them. – Hans Passant Jan 13 '10 at 23:20
  • @nobugz: don't think that's the case. Added more text to the question to clarify. – jcollum Jan 14 '10 at 00:22