top level exception handler behaves differently w/o debugger

[Ben R.]

Hi,

I've got the following code sample to reproduce my issue:

Public Class Form1
Inherits System.Windows.Forms.Form

Shared Sub main()
Try
Application.Run(New Form1)
Catch ex As Exception
Console.WriteLine("Test")
End Try

End Sub

[windows form designer generated code]

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Throw New DivideByZeroException
End Sub
End Class
I added the sub main to insert a top level exception handler in my winforms
app.

When this is run under the debugger, this works as expected. The top level
exception handler grabs the exception and it exits gracefully. Executing
without the debugger, I get the CLR unhandled exception message about an
attempt to divide by zero. Why would the behavior differ?

-Ben

[Kevin Yu [MSFT]]

Hi Ben,

Based on my research, what you are noticing is by design. In .NET
framework, we do not bubble errors that are generated in event handlers to
the application level when there isn't a debugger attached. What we do is
propagate the error through the Application.ThreadException. This is how
1.0 and 1.1 was designed.

So you can handle the Application.ThreadException event for the application
level exception. Here is an KB article for this. HTH.

http://support.microsoft.com/default...b;en-us;836674

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Ben R.]

Hi Kevin,

Thanks for your help. This is similar to what I found as well. When I hooked
up to that event, it was fired both when I was using the debugger and when I
was not. This seemed to require me to abandon the "bubbling" exception model.
I've never encountered a situation before where the flow of execution seems
different depending on the presence of the debugger, before. The article that
you sent is very interesting. Thanks again for your help!

-Ben

"Kevin Yu [MSFT]" wrote:

Hi Ben,

Based on my research, what you are noticing is by design. In .NET
framework, we do not bubble errors that are generated in event handlers to
the application level when there isn't a debugger attached. What we do is
propagate the error through the Application.ThreadException. This is how
1.0 and 1.1 was designed.

So you can handle the Application.ThreadException event for the application
level exception. Here is an KB article for this. HTH.

http://support.microsoft.com/default...b;en-us;836674

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Charles Law]

Hi Kevin

Based on my research, what you are noticing is by design.
Based on the link that you posted I would say that your answer is
inconsistent with reality.

The link clearly states that this is a bug, and therefore not by design,
unless Microsoft is in the habit of designing in bugs to their products.
Perhaps you would care to comment on this? ;-)

Charles
"Kevin Yu [MSFT]" <v-****@online.microsoft.com> wrote in message
news:Bs**************@TK2MSFTNGXA01.phx.gbl... Hi Ben,

Based on my research, what you are noticing is by design. In .NET
framework, we do not bubble errors that are generated in event handlers to
the application level when there isn't a debugger attached. What we do is
propagate the error through the Application.ThreadException. This is how
1.0 and 1.1 was designed.

So you can handle the Application.ThreadException event for the
application
level exception. Here is an KB article for this. HTH.

http://support.microsoft.com/default...b;en-us;836674

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

You're welcome, Ben.

Thanks for sharing your experience with all the people here. If you have
any questions, please feel free to post them in the community.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

In a develpment lifecycle, when bugs are closed, some bugs are closed as by
design, because it is in the designed behavior. Not all bugs are really
bugs. I'm just providing Ben with information that you cannot see.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."