How to get entire chain of Exceptions in Application.ThreadException event handler?

I was just working on fixing up exception handling in a .NET 2.0 app, and I stumbled onto some weird issue with Application.ThreadException.

What I want is to be able to catch all exceptions from events behind GUI elements (e.g. button_Click, etc.). I then want to filter these exceptions on 'fatality', e.g. with some types of Exceptions the application should keep running and with others it should exit.

In another .NET 2.0 app I learned that, by default, only in debug mode the exceptions actually leave an Application.Run or Application.DoEvents call. In release mode this does not happen, and the exceptions have to be 'caught' using the Application.ThreadException event.

Now, however, I noticed that the exception object passed in the ThreadExceptionEventArgs of the Application.ThreadException event is always the innermost exception in the exception chain. For logging/debugging/design purposes I really want the entire chain of exceptions though. It isn't easy to determine what external system failed for example when you just get to handle a SocketException: when it's wrapped as e.g. a NpgsqlException, then at least you know it's a database problem.

So, how to get to the entire chain of exceptions from this event? Is it even possible or do I need to design my excepion handling in another way?

Note that I do -sort of- have a workaround using Application.SetUnhandledExceptionMode, but this is far from ideal because I'd have to roll my own message loop.

EDIT: to prevent more mistakes, the GetBaseException() method does NOT do what I want: it just returns the innermost exception, while the only thing I already have is the innermost exception. I want to get at the outermost exception!

From stackoverflow

• Have you tried the Exception.GetBaseException Method? This returns the exception which created the Application.TreadException. You could then use the same process to go up the chain to get all exceptions.

  exception.getbaseexception Method

  Tobi : GetBaseException does the same as what seems to be happening before Application.ThreadException event is raised: it walks down the chain of exceptions to the innermost exception. (checked it in reflector)

• According to the MSDN documentation:

  When overridden in a derived class, returns the Exception that is the root cause of one or more subsequent exceptions.

      Public Overridable Function GetBaseException() As Exception
          Dim innerException As Exception = Me.InnerException
          Dim exception2 As Exception = Me
          Do While (Not innerException Is Nothing)
              exception2 = innerException
              innerException = innerException.InnerException
          Loop
          Return exception2
      End Function
  

  You could use a variation on this to parse the exception chain.

  Public Sub LogExceptionChain(ByVal CurrentException As Exception)
  
      Dim innerException As Exception = CurrentException.InnerException
      Dim exception2 As Exception = CurrentException
  
      Debug.Print(exception2.Message) 'Log the Exception
  
      Do While (Not innerException Is Nothing)
  
          exception2 = innerException
          Debug.Print(exception2.Message) 'Log the Exception
  
          'Move to the next exception
          innerException = innerException.InnerException
      Loop
  
  End Sub
  

  This would strike me as exactly what you are looking for.

  Tobi : Nope, my problem is I have exactly that in place, but the Exception passed in the ThreadExceptionEventArgs is _already_ the innermost exception, ie. the result of GetBaseException()... IOW, the exception passed in ThreadExceptionEventArgs ALWAYS has a null InnerException property..

• I tried to reproduce this behaviour (always getting the innermost exception),
  but I get the exception I expect, with all InnerExceptions intact.

  Here is the code I used to test:

     Private Shared Sub Test1()
        Try
           Test2()
        Catch ex As Exception
           Application.OnThreadException(New ApplicationException("test1", ex))
        End Try
     End Sub
  
     Private Shared Sub Test2()
        Try
           Test3()
        Catch ex As Exception
           Throw New ApplicationException("test2", ex)
        End Try
     End Sub
  
     Private Shared Sub Test3()
        Throw New ApplicationException("blabla")
     End Sub
  
  Private Shared Sub HandleAppException(ByVal sender As Object, ByVal e As ThreadExceptionEventArgs)
  ...
  End Sub
  

  Sub HandleAppException handles Application.ThreadException. The Test1() method is called first.
  This is the result (e As ThreadExceptionEventArgs) I get in HandleAppException:

  

  If you just catch and (re)throw exceptions, no InnerExceptions wil show up, but it will be appended to the Exception.StackTrace, like this:

  at SO.Test3() in Test.vb:line 166
  at SO.Test2() in Test.vb:line 159
  at SO.Test1() in Test.vb:line 151

• Normally, you only lose the whole exception chain except for the base exception in a Application.ThreadException exception handler if the exception happened in an other thread.

  From the MSDN Library:

  This event allows your Windows Forms application to handle otherwise unhandled exceptions that occur in Windows Forms threads. Attach your event handlers to the ThreadException event to deal with these exceptions, which will leave your application in an unknown state. Where possible, exceptions should be handled by a structured exception handling block.

  Solution: If you do threading, make sure that all your threads/async calls are in a try/catch block. Or as you said, you can play with Application.SetUnhandledExceptionMode.

• This question is more usefully phrased and answered here:

  http://stackoverflow.com/questions/347502/why-does-the-inner-exception-reach-the-threadexception-handler-and-not-the-actual

• Just discovered something interesting. Different GUI events will get you different results. An exception thrown from a Form.Shown event handler will result in Application.ThreadException catching the inner-most exception, but the exact same code run in the Form.Load event will result in the outer-most exception getting caught in Application.ThreadException.