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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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:

> 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@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:0CDFFE23-5AFC-49D0-90DE-8081ED4986A2@xxxxxxxxxxxxxxxx
> |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>>
>
>
>
.

Relevant Pages

  • Unhandled Exception handler
    ... I have a Windows forms app which is started from a sub Main. ... The handler logs details of the exception to a log file as ... When I run the program through the IDE, ... "An unhandled exception has occurred in your application....." ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Unhandled Exception in Form Load in EXE but not in IDE
    ... DebuggableAttribute is not emitted in the result assembly. ... So the answer to your last question about whether or not it's a bug in IDE ... I think customizing the built-in exception dialog is the ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Exception Handling difference between Design-Time and Run-Time
    ... I'm sorry the Debug - Exceptions only works if you don't have a Try/Catch ... Instead I use global Exception handlers, as they largely do what I ... being caught in the IDE as the "bug", while the behavior outside the IDE is ... Public Shared Sub Main ...
    (microsoft.public.dotnet.languages.vb)
  • Debugging under Win7/64 (VB 2008)
    ... If I start from within the IDE and an exception occurs, the debugger does not break. ... Shared Sub main ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Exceptions do not bubble up the call stack!!
    ... The exception is bubbling up but the IDE is not recognising that is ... I don't know if this behaviour counts as a bug or a feature. ...
    (microsoft.public.dotnet.languages.vb)