Exception Handling difference between Design-Time and Run-Time

Here's the example:

Dim frm As New FORM1
Try

frm.show

Catch ex As Exception

msgbox ex.message

End Try

Say FORM1 throws an exception in the load event. Run this in the
Design-Time enviroment and the exception is caught by the code. Run it in
Run-Time and the exception is unhandled.

Some people have said this is a bug. Can you (Microsoft) confirm this for
me please? And confirm whether its a bug in design or run-time? And what
the recomended work round for this is.

Thanks,

Nick Charnock

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/communities...t.languages.vb

Nick,
| Say FORM1 throws an exception in the load event. Run this in the
| Design-Time enviroment and the exception is caught by the code. Run it in
| Run-Time and the exception is unhandled.
The Design-Time enviroment defaults to "If the exception is not handled -
break into the debugger" under "Debug - Exceptions - Common Language Runtime
Exception".

At runtime you do not have an exception handler that handles exceptions in
WIndows Forms Events.

Your try/catch block is only handling events that Form.Show itself throws.

To handle exceptions in the Form.Load event you need to use a Global
Exception Handler.

Depending on the type of application you are creating, .NET has three
different global exception handlers.

For ASP.NET look at:
System.Web.HttpApplication.Error event
Normally placed in your Global.asax file.

For console applications look at:
System.AppDomain.UnhandledException event
Use AddHandler in your Sub Main.

For Windows Forms look at:
System.Windows.Forms.Application.ThreadException event
Use AddHandler in your Sub Main.

It can be beneficial to combine the above global handlers in your app, as
well as wrap your Sub Main in a try catch itself.

There is an article in the June 2004 MSDN Magazine that shows how to
implement the global exception handling in .NET that explains why & when you
use multiple of the above handlers...

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

For example: In my Windows Forms apps I would have a handler attached to the
Application.ThreadException event, plus a Try/Catch in my Main. The
Try/Catch in Main only catches exceptions if the constructor of the MainForm
raises an exception, the Application.ThreadException handler will catch all
uncaught exceptions from any form/control event handlers.

Public Shared Sub Main()
AddHandler Application.ThreadException, AddressOf
Application_ThreadException
Application.EnableVisualStyles()
Application.DoEvents()
Try
Application.Run(New MainForm)
Catch ex As Exception
' log ex for later diagnosis
' optionally show "pretty" version to user
End Try
End Sub

Private Shared Sub Application_ThreadException(ByVal sender As Object,
ByVal e As System.Threading.ThreadExceptionEventArgs)

' Log the e.Exception for later diagnosis.
' optionally show "pretty" version to user

End Sub

Hope this helps
Jay

"chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
news:BF8874D7-F01D-4A82-8B33-4E74A44E6FDB@microsoft.com...
| Here's the example:
|
| Dim frm As New FORM1
| Try
|
| frm.show
|
| Catch ex As Exception
|
| msgbox ex.message
|
| End Try
|
| Say FORM1 throws an exception in the load event. Run this in the
| Design-Time enviroment and the exception is caught by the code. Run it in
| Run-Time and the exception is unhandled.
|
| Some people have said this is a bug. Can you (Microsoft) confirm this for
| me please? And confirm whether its a bug in design or run-time? And what
| the recomended work round for this is.
|
| Thanks,
|
| Nick Charnock
|
|
|
| ----------------
| This post is a suggestion for Microsoft, and Microsoft responds to the
| suggestions with the most votes. To vote for this suggestion, click the "I
| Agree" button in the message pane. If you do not see the button, follow
this
| link to open the suggestion in the Microsoft Web-based Newsreader and then
| click "I Agree" in the message pane.
|
|
http://www.microsoft.com/communities...t.languages.vb

Thanks for the response Jay.

More questions.

Is it possible to make the Design and Run-Time enviroments behave in the
same way?
This is my first VB.NET project (moving from VB6.0) and this problem has
REALLY caught me out.

Also catching the exception at the application level is OK but ideally I
want to catch the exception at the frm.Show level.
Are you saying that this is not possible in .NET???

Thanks,

Nick

"Jay B. Harlow [MVP - Outlook]" wrote:
[color=blue]
> Nick,
> | Say FORM1 throws an exception in the load event. Run this in the
> | Design-Time enviroment and the exception is caught by the code. Run it in
> | Run-Time and the exception is unhandled.
> The Design-Time enviroment defaults to "If the exception is not handled -
> break into the debugger" under "Debug - Exceptions - Common Language Runtime
> Exception".
>
> At runtime you do not have an exception handler that handles exceptions in
> WIndows Forms Events.
>
> Your try/catch block is only handling events that Form.Show itself throws.
>
> To handle exceptions in the Form.Load event you need to use a Global
> Exception Handler.
>
> Depending on the type of application you are creating, .NET has three
> different global exception handlers.
>
> For ASP.NET look at:
> System.Web.HttpApplication.Error event
> Normally placed in your Global.asax file.
>
> For console applications look at:
> System.AppDomain.UnhandledException event
> Use AddHandler in your Sub Main.
>
> For Windows Forms look at:
> System.Windows.Forms.Application.ThreadException event
> Use AddHandler in your Sub Main.
>
> It can be beneficial to combine the above global handlers in your app, as
> well as wrap your Sub Main in a try catch itself.
>
> There is an article in the June 2004 MSDN Magazine that shows how to
> implement the global exception handling in .NET that explains why & when you
> use multiple of the above handlers...
>
> http://msdn.microsoft.com/msdnmag/is...T/default.aspx
>
> For example: In my Windows Forms apps I would have a handler attached to the
> Application.ThreadException event, plus a Try/Catch in my Main. The
> Try/Catch in Main only catches exceptions if the constructor of the MainForm
> raises an exception, the Application.ThreadException handler will catch all
> uncaught exceptions from any form/control event handlers.
>
> Public Shared Sub Main()
> AddHandler Application.ThreadException, AddressOf
> Application_ThreadException
> Application.EnableVisualStyles()
> Application.DoEvents()
> Try
> Application.Run(New MainForm)
> Catch ex As Exception
> ' log ex for later diagnosis
> ' optionally show "pretty" version to user
> End Try
> End Sub
>
> Private Shared Sub Application_ThreadException(ByVal sender As Object,
> ByVal e As System.Threading.ThreadExceptionEventArgs)
>
> ' Log the e.Exception for later diagnosis.
> ' optionally show "pretty" version to user
>
> End Sub
>
> Hope this helps
> Jay
>
>
>
> "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
> news:BF8874D7-F01D-4A82-8B33-4E74A44E6FDB@microsoft.com...
> | Here's the example:
> |
> | Dim frm As New FORM1
> | Try
> |
> | frm.show
> |
> | Catch ex As Exception
> |
> | msgbox ex.message
> |
> | End Try
> |
> | Say FORM1 throws an exception in the load event. Run this in the
> | Design-Time enviroment and the exception is caught by the code. Run it in
> | Run-Time and the exception is unhandled.
> |
> | Some people have said this is a bug. Can you (Microsoft) confirm this for
> | me please? And confirm whether its a bug in design or run-time? And what
> | the recomended work round for this is.
> |
> | Thanks,
> |
> | Nick Charnock
> |
> |
> |
> | ----------------
> | This post is a suggestion for Microsoft, and Microsoft responds to the
> | suggestions with the most votes. To vote for this suggestion, click the "I
> | Agree" button in the message pane. If you do not see the button, follow
> this
> | link to open the suggestion in the Microsoft Web-based Newsreader and then
> | click "I Agree" in the message pane.
> |
> |
> http://www.microsoft.com/communities...t.languages.vb
>
>
>[/color]

Nick,
| Is it possible to make the Design and Run-Time enviroments behave in the
| same way?
Have you tried turning the option I mentioned in the IDE off?

| Also catching the exception at the application level is OK but ideally I
| want to catch the exception at the frm.Show level.
| Are you saying that this is not possible in .NET???
Yes I'm saying its not possible, as that is not how Windows Forms in .NET
works. You could try adding a local handler, Form.Show, Remove the local
handler, however I'm not sure you will get "accurate" results, as another
event (another Win32 message) could throw an exception during the time you
had the local handler attached. Also the form exists for much longer then
the lifetime of Form.Show method.

I understand that the Form.Load event is raised in response to WM_CREATE
Win32 message.

The WM_CREATE message is sent in response to creating the handle to the
underlying Win32 window. When the framework translates Win32 message to
Control/Form Events it wraps raising those events in a Try/Catch that raises
the Application.ThreadException, as normally those messages are processed
via the "message pump", in .NET the "message pump" is the Application.Run
method. In Win32 the "message pump" is a loop that calls the GetMessage,
TranslateMessage, and DispatchMessage Win32 APIs.

Hope this helps
Jay

"chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
news:0CF0A2EA-FA37-461F-AFF1-16459FD798D3@microsoft.com...
| Thanks for the response Jay.
|
| More questions.
|
| Is it possible to make the Design and Run-Time enviroments behave in the
| same way?
| This is my first VB.NET project (moving from VB6.0) and this problem has
| REALLY caught me out.
|
| Also catching the exception at the application level is OK but ideally I
| want to catch the exception at the frm.Show level.
| Are you saying that this is not possible in .NET???
|
| Thanks,
|
| Nick
|
|
| "Jay B. Harlow [MVP - Outlook]" wrote:
|
| > Nick,
| > | Say FORM1 throws an exception in the load event. Run this in the
| > | Design-Time enviroment and the exception is caught by the code. Run
it in
| > | Run-Time and the exception is unhandled.
| > The Design-Time enviroment defaults to "If the exception is not
handled -
| > break into the debugger" under "Debug - Exceptions - Common Language
Runtime
| > Exception".
| >
| > At runtime you do not have an exception handler that handles exceptions
in
| > WIndows Forms Events.
| >
| > Your try/catch block is only handling events that Form.Show itself
throws.
| >
| > To handle exceptions in the Form.Load event you need to use a Global
| > Exception Handler.
| >
| > Depending on the type of application you are creating, .NET has three
| > different global exception handlers.
| >
| > For ASP.NET look at:
| > System.Web.HttpApplication.Error event
| > Normally placed in your Global.asax file.
| >
| > For console applications look at:
| > System.AppDomain.UnhandledException event
| > Use AddHandler in your Sub Main.
| >
| > For Windows Forms look at:
| > System.Windows.Forms.Application.ThreadException event
| > Use AddHandler in your Sub Main.
| >
| > It can be beneficial to combine the above global handlers in your app,
as
| > well as wrap your Sub Main in a try catch itself.
| >
| > There is an article in the June 2004 MSDN Magazine that shows how to
| > implement the global exception handling in .NET that explains why & when
you
| > use multiple of the above handlers...
| >
| > http://msdn.microsoft.com/msdnmag/is...T/default.aspx
| >
| > For example: In my Windows Forms apps I would have a handler attached to
the
| > Application.ThreadException event, plus a Try/Catch in my Main. The
| > Try/Catch in Main only catches exceptions if the constructor of the
MainForm
| > raises an exception, the Application.ThreadException handler will catch
all
| > uncaught exceptions from any form/control event handlers.
| >
| > Public Shared Sub Main()
| > AddHandler Application.ThreadException, AddressOf
| > Application_ThreadException
| > Application.EnableVisualStyles()
| > Application.DoEvents()
| > Try
| > Application.Run(New MainForm)
| > Catch ex As Exception
| > ' log ex for later diagnosis
| > ' optionally show "pretty" version to user
| > End Try
| > End Sub
| >
| > Private Shared Sub Application_ThreadException(ByVal sender As
Object,
| > ByVal e As System.Threading.ThreadExceptionEventArgs)
| >
| > ' Log the e.Exception for later diagnosis.
| > ' optionally show "pretty" version to user
| >
| > End Sub
| >
| > Hope this helps
| > Jay
| >
| >
| >
| > "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
| > news:BF8874D7-F01D-4A82-8B33-4E74A44E6FDB@microsoft.com...
| > | Here's the example:
| > |
| > | Dim frm As New FORM1
| > | Try
| > |
| > | frm.show
| > |
| > | Catch ex As Exception
| > |
| > | msgbox ex.message
| > |
| > | End Try
| > |
| > | Say FORM1 throws an exception in the load event. Run this in the
| > | Design-Time enviroment and the exception is caught by the code. Run
it in
| > | Run-Time and the exception is unhandled.
| > |
| > | Some people have said this is a bug. Can you (Microsoft) confirm this
for
| > | me please? And confirm whether its a bug in design or run-time? And
what
| > | the recomended work round for this is.
| > |
| > | Thanks,
| > |
| > | Nick Charnock
| > |
| > |
| > |
| > | ----------------
| > | This post is a suggestion for Microsoft, and Microsoft responds to the
| > | suggestions with the most votes. To vote for this suggestion, click
the "I
| > | Agree" button in the message pane. If you do not see the button,
follow
| > this
| > | link to open the suggestion in the Microsoft Web-based Newsreader and
then
| > | click "I Agree" in the message pane.
| > |
| > |
| >
http://www.microsoft.com/communities...t.languages.vb
| >
| >
| >

I have tried changing the "Debug - Exceptions - Common Language Runtime>
Exception".
And it does not change the fact that the exception is caught when I run my
App in Design-Time Enviornment and it is not in Run-Time.

This is a major problem. If there is no way round this then are Microsoft
aware of the problem and is it going to be fixed?

Nick

"Jay B. Harlow [MVP - Outlook]" wrote:
[color=blue]
> Nick,
> | Is it possible to make the Design and Run-Time enviroments behave in the
> | same way?
> Have you tried turning the option I mentioned in the IDE off?
>
> | Also catching the exception at the application level is OK but ideally I
> | want to catch the exception at the frm.Show level.
> | Are you saying that this is not possible in .NET???
> Yes I'm saying its not possible, as that is not how Windows Forms in .NET
> works. You could try adding a local handler, Form.Show, Remove the local
> handler, however I'm not sure you will get "accurate" results, as another
> event (another Win32 message) could throw an exception during the time you
> had the local handler attached. Also the form exists for much longer then
> the lifetime of Form.Show method.
>
> I understand that the Form.Load event is raised in response to WM_CREATE
> Win32 message.
>
> The WM_CREATE message is sent in response to creating the handle to the
> underlying Win32 window. When the framework translates Win32 message to
> Control/Form Events it wraps raising those events in a Try/Catch that raises
> the Application.ThreadException, as normally those messages are processed
> via the "message pump", in .NET the "message pump" is the Application.Run
> method. In Win32 the "message pump" is a loop that calls the GetMessage,
> TranslateMessage, and DispatchMessage Win32 APIs.
>
> Hope this helps
> Jay
>
> "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
> news:0CF0A2EA-FA37-461F-AFF1-16459FD798D3@microsoft.com...
> | Thanks for the response Jay.
> |
> | More questions.
> |
> | Is it possible to make the Design and Run-Time enviroments behave in the
> | same way?
> | This is my first VB.NET project (moving from VB6.0) and this problem has
> | REALLY caught me out.
> |
> | Also catching the exception at the application level is OK but ideally I
> | want to catch the exception at the frm.Show level.
> | Are you saying that this is not possible in .NET???
> |
> | Thanks,
> |
> | Nick
> |
> |
> | "Jay B. Harlow [MVP - Outlook]" wrote:
> |
> | > Nick,
> | > | Say FORM1 throws an exception in the load event. Run this in the
> | > | Design-Time enviroment and the exception is caught by the code. Run
> it in
> | > | Run-Time and the exception is unhandled.
> | > The Design-Time enviroment defaults to "If the exception is not
> handled -
> | > break into the debugger" under "Debug - Exceptions - Common Language
> Runtime
> | > Exception".
> | >
> | > At runtime you do not have an exception handler that handles exceptions
> in
> | > WIndows Forms Events.
> | >
> | > Your try/catch block is only handling events that Form.Show itself
> throws.
> | >
> | > To handle exceptions in the Form.Load event you need to use a Global
> | > Exception Handler.
> | >
> | > Depending on the type of application you are creating, .NET has three
> | > different global exception handlers.
> | >
> | > For ASP.NET look at:
> | > System.Web.HttpApplication.Error event
> | > Normally placed in your Global.asax file.
> | >
> | > For console applications look at:
> | > System.AppDomain.UnhandledException event
> | > Use AddHandler in your Sub Main.
> | >
> | > For Windows Forms look at:
> | > System.Windows.Forms.Application.ThreadException event
> | > Use AddHandler in your Sub Main.
> | >
> | > It can be beneficial to combine the above global handlers in your app,
> as
> | > well as wrap your Sub Main in a try catch itself.
> | >
> | > There is an article in the June 2004 MSDN Magazine that shows how to
> | > implement the global exception handling in .NET that explains why & when
> you
> | > use multiple of the above handlers...
> | >
> | > http://msdn.microsoft.com/msdnmag/is...T/default.aspx
> | >
> | > For example: In my Windows Forms apps I would have a handler attached to
> the
> | > Application.ThreadException event, plus a Try/Catch in my Main. The
> | > Try/Catch in Main only catches exceptions if the constructor of the
> MainForm
> | > raises an exception, the Application.ThreadException handler will catch
> all
> | > uncaught exceptions from any form/control event handlers.
> | >
> | > Public Shared Sub Main()
> | > AddHandler Application.ThreadException, AddressOf
> | > Application_ThreadException
> | > Application.EnableVisualStyles()
> | > Application.DoEvents()
> | > Try
> | > Application.Run(New MainForm)
> | > Catch ex As Exception
> | > ' log ex for later diagnosis
> | > ' optionally show "pretty" version to user
> | > End Try
> | > End Sub
> | >
> | > Private Shared Sub Application_ThreadException(ByVal sender As
> Object,
> | > ByVal e As System.Threading.ThreadExceptionEventArgs)
> | >
> | > ' Log the e.Exception for later diagnosis.
> | > ' optionally show "pretty" version to user
> | >
> | > End Sub
> | >
> | > Hope this helps
> | > Jay
> | >
> | >
> | >
> | > "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
> | > news:BF8874D7-F01D-4A82-8B33-4E74A44E6FDB@microsoft.com...
> | > | Here's the example:
> | > |
> | > | Dim frm As New FORM1
> | > | Try
> | > |
> | > | frm.show
> | > |
> | > | Catch ex As Exception
> | > |
> | > | msgbox ex.message
> | > |
> | > | End Try
> | > |
> | > | Say FORM1 throws an exception in the load event. Run this in the
> | > | Design-Time enviroment and the exception is caught by the code. Run
> it in
> | > | Run-Time and the exception is unhandled.
> | > |
> | > | Some people have said this is a bug. Can you (Microsoft) confirm this
> for
> | > | me please? And confirm whether its a bug in design or run-time? And
> what
> | > | the recomended work round for this is.
> | > |
> | > | Thanks,
> | > |
> | > | Nick Charnock
> | > |
> | > |
> | > |
> | > | ----------------
> | > | This post is a suggestion for Microsoft, and Microsoft responds to the
> | > | suggestions with the most votes. To vote for this suggestion, click
> the "I
> | > | Agree" button in the message pane. If you do not see the button,
> follow
> | > this
> | > | link to open the suggestion in the Microsoft Web-based Newsreader and
> then
> | > | click "I Agree" in the message pane.
> | > |
> | > |
> | >
> http://www.microsoft.com/communities...t.languages.vb
> | >
> | >
> | >
>
>
>[/color]

Nick,
I'm sorry the Debug - Exceptions only works if you don't have a Try/Catch
around the Form.Show.

I don't put Try/Catch's around Form.Show as they don't really do what one
might think they should (which may be the alledged bug you were referring
to). Instead I use global Exception handlers, as they largely do what I
would expect them to.

| This is a major problem. If there is no way round this then are Microsoft
| aware of the problem and is it going to be fixed?
I believe we may have a difference of opinion here, as I see the exception
being caught in the IDE as the "bug", while the behavior outside the IDE is
what I would expect to happen. Based on my explanation of how Win32 events
occur.

After all how your program behaves outside the IDE is how your program is
going to behave in the "wild".

Although I agree in the case of Form.Load (and only Form.Load) it could be
beneficial to have a Try/Catch around Form.Show catch the exception. I know
some developers think that a Try/Catch around Form.Show & its close cousin
Application.Run should catch any Exception that any Form/Control level event
doesn't handle...

However I will try to verify what VS.NET 2005 does later today.

On the surface, it appears that if you handle the
Application.ThreadException & simply rethrow the exception then the
Try/Catch around Form.Show will behave as you expect. HOWEVER!!! This can
have serious determents to your code elsewhere. As you can't be certain of
the order that event handlers were added to Application.ThreadException,
plus you may catch exceptions that weren't meant to be caught...

You might try something like:

Public Shared Sub Main()
AddHandler Application.ThreadException, AddressOf
Application_ThreadException

Application.EnableVisualStyles()
Application.DoEvents()
Application.Run(New MainForm)
End Sub

Private Shared Sub Application_ThreadException(ByVal sender As Object,
ByVal e As System.Threading.ThreadExceptionEventArgs)
MessageBox.Show("Application_ThreadException" & ControlChars.CrLf &
ControlChars.CrLf & e.Exception.ToString(), Application.ProductName)
Debug.WriteLine(e.Exception.ToString())
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim child As New ChildForm
Try
' HACK: Try & catch exceptions from ChildForm.Load
AddHandler Application.ThreadException, AddressOf
Show_ThreadException
child.Show()
Catch ex As Exception
MessageBox.Show("Button1_Click" & ControlChars.CrLf &
ControlChars.CrLf & ex.ToString(), Application.ProductName)
Debug.WriteLine(ex.ToString())
Finally
' HACK: Try & catch exceptions from ChildForm.Load
RemoveHandler Application.ThreadException, AddressOf
Show_ThreadException
End Try
End Sub

' HACK: Try & catch exceptions from ChildForm.Load
Private Shared Sub Show_ThreadException(ByVal sender As Object, ByVal e
As System.Threading.ThreadExceptionEventArgs)
MessageBox.Show("Show_ThreadException" & ControlChars.CrLf &
ControlChars.CrLf & e.Exception.ToString(), Application.ProductName)
Debug.WriteLine(e.Exception.ToString(), "Show_ThreadException")
Throw e.Exception
End Sub

I say "on the surface" as I did minimal testing from the IDE with both
'Debug - Start' & 'Debug - Start without Debugging' and testing from Windows
Explorer.

Hope this helps
Jay

"chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
news:0CDFFE23-5AFC-49D0-90DE-8081ED4986A2@microsoft.com...
|I have tried changing the "Debug - Exceptions - Common Language Runtime>
| Exception".
| And it does not change the fact that the exception is caught when I run my
| App in Design-Time Enviornment and it is not in Run-Time.
|
| This is a major problem. If there is no way round this then are Microsoft
| aware of the problem and is it going to be fixed?
|
| Nick
|
<<snip>>

thanks for this Jay. its very helpful.

About the bug. I'm not saying either way whether its the IDE thats at fault
or the runtime. Just that the behaviour should be consistent in both.

PS i'm using VS.NET 2003, so if you can't duplicate it its time to think
about upgrading.

Nick

"Jay B. Harlow [MVP - Outlook]" wrote:
[color=blue]
> Nick,
> I'm sorry the Debug - Exceptions only works if you don't have a Try/Catch
> around the Form.Show.
>
> I don't put Try/Catch's around Form.Show as they don't really do what one
> might think they should (which may be the alledged bug you were referring
> to). Instead I use global Exception handlers, as they largely do what I
> would expect them to.
>
> | This is a major problem. If there is no way round this then are Microsoft
> | aware of the problem and is it going to be fixed?
> I believe we may have a difference of opinion here, as I see the exception
> being caught in the IDE as the "bug", while the behavior outside the IDE is
> what I would expect to happen. Based on my explanation of how Win32 events
> occur.
>
> After all how your program behaves outside the IDE is how your program is
> going to behave in the "wild".
>
> Although I agree in the case of Form.Load (and only Form.Load) it could be
> beneficial to have a Try/Catch around Form.Show catch the exception. I know
> some developers think that a Try/Catch around Form.Show & its close cousin
> Application.Run should catch any Exception that any Form/Control level event
> doesn't handle...
>
> However I will try to verify what VS.NET 2005 does later today.
>
> On the surface, it appears that if you handle the
> Application.ThreadException & simply rethrow the exception then the
> Try/Catch around Form.Show will behave as you expect. HOWEVER!!! This can
> have serious determents to your code elsewhere. As you can't be certain of
> the order that event handlers were added to Application.ThreadException,
> plus you may catch exceptions that weren't meant to be caught...
>
> You might try something like:
>
> Public Shared Sub Main()
> AddHandler Application.ThreadException, AddressOf
> Application_ThreadException
>
> Application.EnableVisualStyles()
> Application.DoEvents()
> Application.Run(New MainForm)
> End Sub
>
> Private Shared Sub Application_ThreadException(ByVal sender As Object,
> ByVal e As System.Threading.ThreadExceptionEventArgs)
> MessageBox.Show("Application_ThreadException" & ControlChars.CrLf &
> ControlChars.CrLf & e.Exception.ToString(), Application.ProductName)
> Debug.WriteLine(e.Exception.ToString())
> End Sub
>
> Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
> System.EventArgs) Handles Button1.Click
> Dim child As New ChildForm
> Try
> ' HACK: Try & catch exceptions from ChildForm.Load
> AddHandler Application.ThreadException, AddressOf
> Show_ThreadException
> child.Show()
> Catch ex As Exception
> MessageBox.Show("Button1_Click" & ControlChars.CrLf &
> ControlChars.CrLf & ex.ToString(), Application.ProductName)
> Debug.WriteLine(ex.ToString())
> Finally
> ' HACK: Try & catch exceptions from ChildForm.Load
> RemoveHandler Application.ThreadException, AddressOf
> Show_ThreadException
> End Try
> End Sub
>
> ' HACK: Try & catch exceptions from ChildForm.Load
> Private Shared Sub Show_ThreadException(ByVal sender As Object, ByVal e
> As System.Threading.ThreadExceptionEventArgs)
> MessageBox.Show("Show_ThreadException" & ControlChars.CrLf &
> ControlChars.CrLf & e.Exception.ToString(), Application.ProductName)
> Debug.WriteLine(e.Exception.ToString(), "Show_ThreadException")
> Throw e.Exception
> End Sub
>
> I say "on the surface" as I did minimal testing from the IDE with both
> 'Debug - Start' & 'Debug - Start without Debugging' and testing from Windows
> Explorer.
>
>
> Hope this helps
> Jay
>
> "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
> news:0CDFFE23-5AFC-49D0-90DE-8081ED4986A2@microsoft.com...
> |I have tried changing the "Debug - Exceptions - Common Language Runtime>
> | Exception".
> | And it does not change the fact that the exception is caught when I run my
> | App in Design-Time Enviornment and it is not in Run-Time.
> |
> | This is a major problem. If there is no way round this then are Microsoft
> | aware of the problem and is it going to be fixed?
> |
> | Nick
> |
> <<snip>>
>
>
>[/color]

Nick,
VS.NET 2005 has the same feature...

This feature makes me think of the Heisenberg Uncertainty Principle. "As
soon as you try and measure something you end up affecting the measure" or
in this case as soon as you try to debug your app, you modify the behavior
of your app. ;-)

The problem/feature seems to be related to the NativeWindow.Callback verses
NativeWindow.DebuggableCallback methods. NativeWindow.DebuggableCallback
appears in the call stack when you are running under VS.NET & you do not
have the global exception handler in the sub main... If outside VS.NET or
you have the global exception handler in the sub main, then I only see
NativeWindow.Callback... Note having the global exception handler in the
Try/Catch does not seem to effect which routine is used...

Seeing as I normally have the global exception handler in my sub main, to
catch unhandled exceptions in all my Control event methods, I've never
really noticed this behavior before... I strongly recommend having the
global exception handler in your sub main, for the reasons identified in the
this previously mentioned article:

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

Mainly that it prevents unhandled exceptions in your code & it allows you to
avoid duplicating try/catch blocks in each of your event procedures...

| About the bug. I'm not saying either way whether its the IDE thats at
fault
| or the runtime. Just that the behavior should be consistent in both.

As far as I can tell, once you have the above global exception handler the
behavior then becomes the same!

Hope this helps
Jay

"chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
news:EE651625-09B8-48EA-81AF-72FB3550B3E0@microsoft.com...
| thanks for this Jay. its very helpful.
|
| About the bug. I'm not saying either way whether its the IDE thats at
fault
| or the runtime. Just that the behaviour should be consistent in both.
|
| PS i'm using VS.NET 2003, so if you can't duplicate it its time to think
| about upgrading.
|
| Nick
|
<<snip>>

Thanks for that Jay, helps alot.

Can you tell me, are MS aware of the problem?
If not how do I report it to them.

Thanks,

Nick

"Jay B. Harlow [MVP - Outlook]" wrote:
[color=blue]
> Nick,
> VS.NET 2005 has the same feature...
>
> This feature makes me think of the Heisenberg Uncertainty Principle. "As
> soon as you try and measure something you end up affecting the measure" or
> in this case as soon as you try to debug your app, you modify the behavior
> of your app. ;-)
>
> The problem/feature seems to be related to the NativeWindow.Callback verses
> NativeWindow.DebuggableCallback methods. NativeWindow.DebuggableCallback
> appears in the call stack when you are running under VS.NET & you do not
> have the global exception handler in the sub main... If outside VS.NET or
> you have the global exception handler in the sub main, then I only see
> NativeWindow.Callback... Note having the global exception handler in the
> Try/Catch does not seem to effect which routine is used...
>
>
> Seeing as I normally have the global exception handler in my sub main, to
> catch unhandled exceptions in all my Control event methods, I've never
> really noticed this behavior before... I strongly recommend having the
> global exception handler in your sub main, for the reasons identified in the
> this previously mentioned article:
>
> http://msdn.microsoft.com/msdnmag/is...T/default.aspx
>
> Mainly that it prevents unhandled exceptions in your code & it allows you to
> avoid duplicating try/catch blocks in each of your event procedures...
>
> | About the bug. I'm not saying either way whether its the IDE thats at
> fault
> | or the runtime. Just that the behavior should be consistent in both.
>
> As far as I can tell, once you have the above global exception handler the
> behavior then becomes the same!
>
> Hope this helps
> Jay
>
>
> "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
> news:EE651625-09B8-48EA-81AF-72FB3550B3E0@microsoft.com...
> | thanks for this Jay. its very helpful.
> |
> | About the bug. I'm not saying either way whether its the IDE thats at
> fault
> | or the runtime. Just that the behaviour should be consistent in both.
> |
> | PS i'm using VS.NET 2003, so if you can't duplicate it its time to think
> | about upgrading.
> |
> | Nick
> |
> <<snip>>
>
>
>[/color]

Thanks

"Jay B. Harlow [MVP - Outlook]" wrote:
[color=blue]
> Nick,
> You can report bugs & make suggestions on VS.NET 2005 here:
>
> http://lab.msdn.microsoft.com/vs2005/
>
> Hope this helps
> Jay
>
> "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
> news:537FD62F-C10A-4341-BFCE-342838529630@microsoft.com...
> | Thanks for that Jay, helps alot.
> |
> | Can you tell me, are MS aware of the problem?
> | If not how do I report it to them.
> |
> | Thanks,
> |
> | Nick
> |
> | "Jay B. Harlow [MVP - Outlook]" wrote:
> |
> | > Nick,
> | > VS.NET 2005 has the same feature...
> | >
> | > This feature makes me think of the Heisenberg Uncertainty Principle. "As
> | > soon as you try and measure something you end up affecting the measure"
> or
> | > in this case as soon as you try to debug your app, you modify the
> behavior
> | > of your app. ;-)
> | >
> | > The problem/feature seems to be related to the NativeWindow.Callback
> verses
> | > NativeWindow.DebuggableCallback methods. NativeWindow.DebuggableCallback
> | > appears in the call stack when you are running under VS.NET & you do not
> | > have the global exception handler in the sub main... If outside VS.NET
> or
> | > you have the global exception handler in the sub main, then I only see
> | > NativeWindow.Callback... Note having the global exception handler in the
> | > Try/Catch does not seem to effect which routine is used...
> | >
> | >
> | > Seeing as I normally have the global exception handler in my sub main,
> to
> | > catch unhandled exceptions in all my Control event methods, I've never
> | > really noticed this behavior before... I strongly recommend having the
> | > global exception handler in your sub main, for the reasons identified in
> the
> | > this previously mentioned article:
> | >
> | > http://msdn.microsoft.com/msdnmag/is...T/default.aspx
> | >
> | > Mainly that it prevents unhandled exceptions in your code & it allows
> you to
> | > avoid duplicating try/catch blocks in each of your event procedures...
> | >
> | > | About the bug. I'm not saying either way whether its the IDE thats at
> | > fault
> | > | or the runtime. Just that the behavior should be consistent in both.
> | >
> | > As far as I can tell, once you have the above global exception handler
> the
> | > behavior then becomes the same!
> | >
> | > Hope this helps
> | > Jay
> | >
> | >
> | > "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
> | > news:EE651625-09B8-48EA-81AF-72FB3550B3E0@microsoft.com...
> | > | thanks for this Jay. its very helpful.
> | > |
> | > | About the bug. I'm not saying either way whether its the IDE thats at
> | > fault
> | > | or the runtime. Just that the behaviour should be consistent in both.
> | > |
> | > | PS i'm using VS.NET 2003, so if you can't duplicate it its time to
> think
> | > | about upgrading.
> | > |
> | > | Nick
> | > |
> | > <<snip>>
> | >
> | >
> | >
>
>
>[/color]

Nick,
In case you were following this thread.

Here is an KB article that I found talking about this topic:

http://support.microsoft.com/?kbid=836674

Hope this helps
Jay

"chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
news:40AA00EE-C126-4C47-BF01-81B427F562DA@microsoft.com...
| Thanks
|
| "Jay B. Harlow [MVP - Outlook]" wrote:
|
| > Nick,
| > You can report bugs & make suggestions on VS.NET 2005 here:
| >
| > http://lab.msdn.microsoft.com/vs2005/
| >
| > Hope this helps
| > Jay
| >
| > "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in message
| > news:537FD62F-C10A-4341-BFCE-342838529630@microsoft.com...
| > | Thanks for that Jay, helps alot.
| > |
| > | Can you tell me, are MS aware of the problem?
| > | If not how do I report it to them.
| > |
| > | Thanks,
| > |
| > | Nick
| > |
| > | "Jay B. Harlow [MVP - Outlook]" wrote:
| > |
| > | > Nick,
| > | > VS.NET 2005 has the same feature...
| > | >
| > | > This feature makes me think of the Heisenberg Uncertainty Principle.
"As
| > | > soon as you try and measure something you end up affecting the
measure"
| > or
| > | > in this case as soon as you try to debug your app, you modify the
| > behavior
| > | > of your app. ;-)
| > | >
| > | > The problem/feature seems to be related to the NativeWindow.Callback
| > verses
| > | > NativeWindow.DebuggableCallback methods.
NativeWindow.DebuggableCallback
| > | > appears in the call stack when you are running under VS.NET & you do
not
| > | > have the global exception handler in the sub main... If outside
VS.NET
| > or
| > | > you have the global exception handler in the sub main, then I only
see
| > | > NativeWindow.Callback... Note having the global exception handler in
the
| > | > Try/Catch does not seem to effect which routine is used...
| > | >
| > | >
| > | > Seeing as I normally have the global exception handler in my sub
main,
| > to
| > | > catch unhandled exceptions in all my Control event methods, I've
never
| > | > really noticed this behavior before... I strongly recommend having
the
| > | > global exception handler in your sub main, for the reasons
identified in
| > the
| > | > this previously mentioned article:
| > | >
| > | > http://msdn.microsoft.com/msdnmag/is...T/default.aspx
| > | >
| > | > Mainly that it prevents unhandled exceptions in your code & it
allows
| > you to
| > | > avoid duplicating try/catch blocks in each of your event
procedures...
| > | >
| > | > | About the bug. I'm not saying either way whether its the IDE
thats at
| > | > fault
| > | > | or the runtime. Just that the behavior should be consistent in
both.
| > | >
| > | > As far as I can tell, once you have the above global exception
handler
| > the
| > | > behavior then becomes the same!
| > | >
| > | > Hope this helps
| > | > Jay
| > | >
| > | >
| > | > "chopsnsauce" <chopsnsauce@discussions.microsoft.com> wrote in
message
| > | > news:EE651625-09B8-48EA-81AF-72FB3550B3E0@microsoft.com...
| > | > | thanks for this Jay. its very helpful.
| > | > |
| > | > | About the bug. I'm not saying either way whether its the IDE
thats at
| > | > fault
| > | > | or the runtime. Just that the behaviour should be consistent in
both.
| > | > |
| > | > | PS i'm using VS.NET 2003, so if you can't duplicate it its time
to
| > think
| > | > | about upgrading.
| > | > |
| > | > | Nick
| > | > |
| > | > <<snip>>
| > | >
| > | >
| > | >
| >
| >
| >

Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

re: Exception Handling difference between Design-Time and Run-Time

Similar Visual Basic .NET bytes

/bytes/development

/bytes/it

/bytes/about