2

My current install of Visual Studio 2015 will not allow me to throw an unhandled exception while running code from the IDE. I want to exercise my unhandled exception code but my code:

Private Sub btnTest_Click(sender As System.Object, e As System.EventArgs) Handles btnTest.Click
    Throw New System.Exception("An unhandled test exception has occurred.")
End Sub

only works during a normal runtime, not when the code is executed in the IDE.

How can I debug my unhandled exception code in the IDE?

I looked in Debug, Windows, Exception Settings but I don't see a way to do what I want to do. Is there another more global setting that will allow an unhandled exception without the IDE capturing the exception?


I'm using the ApplicationsEvents.vb to hook the event:

Namespace My

' The following events are available for MyApplication:
' 
' Startup: Raised when the application starts, before the startup form is created.
' Shutdown: Raised after all application forms are closed.  This event is not raised if the application terminates abnormally.
' UnhandledException: Raised if the application encounters an unhandled exception.
' StartupNextInstance: Raised when launching a single-instance application and the application is already active. 
' NetworkAvailabilityChanged: Raised when the network connection is connected or disconnected.
Partial Friend Class MyApplication
    Private Sub MyApplication_UnhandledException(sender As Object, e As Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) Handles Me.UnhandledException
        ExpLog.LogUnhandledException(e, sender)
        e.ExitApplication = Not ExpLog.InformUser
    End Sub
End Class
End Namespace

Resolution was to create a test stub that exercised the code that was called by the handler:

Private Sub Button6_Click(sender As System.Object, e As System.EventArgs) Handles btnMisc_Throw.Click

    If ExpLog.InformUser() Then
        MsgBox("Continue")
    Else
        MsgBox("End Program")
    End If

    ExpLog.LogMsgBox(New System.Exception("test unhandled exception"), "test LogMsgBox()",,, "programmer note")

End Sub

This doesn't allow for testing the handler but it does exercise the code the handler calls. Looking at some old comments I figured this out five+ years ago... :(

rheitzman
  • 2,247
  • 3
  • 20
  • 36
  • My `bntTest_Click` code is on a child form inside a MDI parent form. – rheitzman Nov 14 '16 at 22:23
  • After seeing your edit in ApplicationEvents, this is different from how I added the handler. I tried your code and confirm it doesn't work. Try the way I did if possible. – djv Nov 14 '16 at 22:30
  • I tried throwing the test exception from the MDI container (form level) and it fails as well. Your way worked on a standalone form but I need to capture the unhandled events at the application level as I have a mix of standalone and MDI-Child forms. – rheitzman Nov 14 '16 at 22:38
  • Being MDI sheds more light. I have a very similar situation with MDI, but I found running my application from a a hidden form then launching my MDI form with `Application.Run(myForm)` allowed me to use `AddHandler AppDomain.CurrentDomain.UnhandledException...` and `AddHandler Application.ThreadException...` which work in debug and release. `Application.Run(myForm)` can even be put inside a `Try..Catch` for anything which slipped through. I would be able to put an example together tomorrow. – djv Nov 14 '16 at 22:48
  • See final edit above - I guess I really didn't need to throw an unhandled exception, I just needed to replicate the code in the handler. This doesn't debug the handler, but does what I needed. – rheitzman Nov 14 '16 at 22:55
  • If you go to Debug > Exceptions, do you have anything checked there? – Chris Dunaway Nov 15 '16 at 14:46

1 Answers1

0

Add a handler to AppDomain.CurrentDomain.UnhandledException

Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf UnhandledExceptionHandler
End Sub

Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    Throw New System.Exception("An unhandled test exception has occurred.")
End Sub

Public Shared Sub UnhandledExceptionHandler(ByVal sender As Object, ByVal args As UnhandledExceptionEventArgs)
    MessageBox.Show(CType(args.ExceptionObject, Exception).Message)
End Sub
djv
  • 15,168
  • 7
  • 48
  • 72
  • 2
    I have the handler in place, works when the exe is run outside the IDE. I am trying to debug the handler from the IDE. When I throw an unhandled exception, as in the post, the IDE halts and will not invoke the handler. – rheitzman Nov 14 '16 at 21:28
  • Strange, my IDE invokes the handler *then* halts on the exception. Running Win7x64 VS2012 v4.6, my experience seems to jive with http://stackoverflow.com/questions/406385/handling-unhandled-exceptions-problem – djv Nov 14 '16 at 21:47
  • I think the difference may be C# vs VB.net and the VB Application Events feature of Visual Studio. Could be 2012 vs 2015 as I thought I could debug this event once upon a time. – rheitzman Nov 14 '16 at 22:15
  • But my small example in VB works as I said, in that the handler is invoked then execution halts on the `Throw New Exception` line. This is what happens in the post I linked. I felt like that would be workable in debug. It seems your problem is that you don't even get to the handler. This is a different problem altogether. – djv Nov 14 '16 at 22:18
  • It is true I don't get to the handler - it displays the unhandled exception dialog on `throw new exception` and I'm done as far as debugging in the IDE goes. See edit (in a few minutes.) – rheitzman Nov 14 '16 at 22:22
  • Does it work if you make a new winforms app and paste my example into `Class Form1`? – djv Nov 14 '16 at 22:24
  • Sort of - the handler fires and displays the message but the IDE displays the unhandled exception dialog. If I hit continue/run to displays the message again in a loop until the program is halted. See comment on OP - I think I'm down a couple of layers. – rheitzman Nov 14 '16 at 22:31
  • ApplicationEvents vs. my way above produce different results in debug. Mine will allow you to debug the handler, while ApplicationEvents appears not to. Though mine does halt where the exception originated *after* the handler is invoked, I think this is manageable for debug. They probably both work the same when not debugging, i.e. release. – djv Nov 14 '16 at 22:34