locked
Catching thread+form exceptions RRS feed

  • Question

  • Hello

    My application creates a thread. The thread creates a Form and Application.Run() it.

    Public Sub MyThread() try AddHandler Windows.Forms.Application.ThreadException, AddressOf MyExceptHandler Windows.Forms.Application.Run(mMainForm)

    Catch ex As Exception MsgBox("catch") End Try End Sub Private Sub MyExceptHandler(ByVal sender As Object, ByVal e As ThreadExceptionEventArgs) MsgBox("MyExceptHandler") End Sub

    During tests I've notice a change of behavior wether I am attached to the application with the debugger or not. With the debugger attached the "catch" message box is called. If I am not attached, then the "MyExceptHandler" message box is called. Is this normal ? When I was not attached, I was wondering why I had a "unhandled exception"  message, despire having a catch clause. I need to do some processing after an exception, so I would have to call the processing code both in the Cath clause and in the MyExceptHandler ?


    Just find out that if I attach the debugger before the Thread/Form is created then when there is an exception, the Catch  block is called. If I attach the debugger after the Thread/Form is created, the handler is called and not the Catch ?

    I have a button on the form which throws an exception for testing purposes.
    • Edited by DirectCast Friday, January 24, 2014 9:19 PM
    Friday, January 24, 2014 8:56 PM

Answers

  • Is Visual Studio hosting process enabled ? That comes into picture when VS debugger is attached.

    http://msdn.microsoft.com/en-us/library/ms242202.aspx

    If yes, try disabling it. It should give consistent result when an error is thrown from a thread regardeless of a debugger is attached or not if this process is disabled.


    Do not Forget to Vote as Answer/Helpful, please. It encourages us to help you...

    • Marked as answer by DirectCast Wednesday, January 29, 2014 3:45 PM
    Friday, January 24, 2014 9:17 PM

All replies

  • Is Visual Studio hosting process enabled ? That comes into picture when VS debugger is attached.

    http://msdn.microsoft.com/en-us/library/ms242202.aspx

    If yes, try disabling it. It should give consistent result when an error is thrown from a thread regardeless of a debugger is attached or not if this process is disabled.


    Do not Forget to Vote as Answer/Helpful, please. It encourages us to help you...

    • Marked as answer by DirectCast Wednesday, January 29, 2014 3:45 PM
    Friday, January 24, 2014 9:17 PM
  • Hello

    I have disabled the hosting process. There is no change in behavior. From my understanding, there is no vshost process, since my application is not started by VS. I attach to a ATL C++ COM out-proc server, which instantiate my VB.NET COM component. Its a new component and I am fine tuning the exception handling.

    Monday, January 27, 2014 2:22 PM
  • Anyway, since the behavior is predictable, I have adapted the code to handled the three scenarios:

    1. If the debugger is attached before the thread/form creation, then if an exception occurs, the catch block will be called. The form will be closed. The thread will stop.

    2. If the debugger is attached after the thread/form creation, then if an exception occurs, the Application.ThreadException code will be called. the form is not closed. It must be closed manually to terminate the thread.

    3. If no debugger is attached, scenario 2 is used.

    Tuesday, January 28, 2014 2:08 PM
  • Just found how to make sure the Catch clause is always called. In the unhandled exception of the form thread, just rethrow the exception, then the Catch block will be called:

        Private Shared Sub MainFrmThreadExceptionHandler(ByVal sender As Object, ByVal e As ThreadExceptionEventArgs)
            Throw e.Exception
        End Sub

    This seems to provide constant behavior, debugger or not. My newbee mistake !

    (I got the idea from reading about Thread.Abort)

    Wednesday, January 29, 2014 3:28 PM