Reputation: 81743
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!
Upvotes: 5
Views: 2961
Reputation: 11
Based on some of the information in this chain, I used UnhandledExceptionMode.ThrowException as opposed to UnhandledExceptionMode.CatchException. I then catch the exception outside the form's Run() and this gives me the entire chain of exceptions.
Upvotes: 1
Reputation: 123
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.
Upvotes: 1
Reputation: 593
This question is more usefully phrased and answered here:
Why does the inner exception reach the ThreadException handler and not the actual thrown exception?
Upvotes: 4
Reputation: 121384
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.
Upvotes: 1
Reputation: 5575
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:
ThreadException http://mediasensation.be/dump/?download=ThreadException.jpg
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
Upvotes: 1
Reputation: 2158
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.
Upvotes: -1
Reputation: 2158
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
Upvotes: 0