views:

972

answers:

6

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!

A: 

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

Leo Moore
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)
Tobi
A: 

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.

Leo Moore
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..
Tobi
+1  A: 
Vincent Van Den Berghe
+1  A: 

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.

DrJokepu
+2  A: 

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

Ashley Tate
+1  A: 

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.

iszzypop