By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,645 Members | 1,048 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,645 IT Pros & Developers. It's quick & easy.

Exceptions dont "bubble up" in standalone EXE, but DO in the Visual Studio mode

P: n/a
Hi all. In my program I try to handle all obvious potential errors with
structured error handling (try-catch) block. What I would like to do is
have an 'overall' error handler that would gracefully catch any
unanticipated errors. I created a startup module to place my overall error
handling for my "real" program which is Form1. My program is structured
like this:

Module startup

..

public sub Main()

.. try

.. application.run(new Form1) 'this is line 45 of module startup

..catch ex as exception

msgbox(ex.tostring)

end try

end sub

end module

Within the Form1 application I put a button that, when clicked, throws an
exception:

Button1Click

Throw new exception("error occurred") 'this is line 899 of Form1

Here's the problem. When I run inside the VisualStudio environment the
exception works exactly as I would expect. That is, my messagebox displays
the full stack trace pointing to line 899 of form1 and 45 of startup.
Again, this is what I would expect.

However, when I build the appl and run it standalone, the same button
displays a popup window that says it is an unhandled exception, and does not
give stack trace info.

Here's the good part.. if I put the "Throw new exception" into a Try-Catch
block then when I run it standalone it DOES give me stack trace info. So,
it seems like when I run it as a standalone exe the exception does not
"bubble up" to the next higher level of error handling as I think it should.

Can anybody shed some light on this behavior? Thanks.
Nov 21 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hi John

Try adding this Event handler to your startup code:
AddHandler Application.ThreadException, AddressOf Bla

And then you will get unhandled exceptions in the Exception property of your
ThreadExceptionEventArgs object.

Public Sub Bla(ByVal sender As Object, ByVal e As
System.Threading.ThreadExceptionEventArgs)

End Sub

HTH

Nigel

"JohnR" wrote:
Hi all. In my program I try to handle all obvious potential errors with
structured error handling (try-catch) block. What I would like to do is
have an 'overall' error handler that would gracefully catch any
unanticipated errors. I created a startup module to place my overall error
handling for my "real" program which is Form1. My program is structured
like this:

Module startup

..

public sub Main()

.. try

.. application.run(new Form1) 'this is line 45 of module startup

..catch ex as exception

msgbox(ex.tostring)

end try

end sub

end module

Within the Form1 application I put a button that, when clicked, throws an
exception:

Button1Click

Throw new exception("error occurred") 'this is line 899 of Form1

Here's the problem. When I run inside the VisualStudio environment the
exception works exactly as I would expect. That is, my messagebox displays
the full stack trace pointing to line 899 of form1 and 45 of startup.
Again, this is what I would expect.

However, when I build the appl and run it standalone, the same button
displays a popup window that says it is an unhandled exception, and does not
give stack trace info.

Here's the good part.. if I put the "Throw new exception" into a Try-Catch
block then when I run it standalone it DOES give me stack trace info. So,
it seems like when I run it as a standalone exe the exception does not
"bubble up" to the next higher level of error handling as I think it should.

Can anybody shed some light on this behavior? Thanks.

Nov 21 '05 #2

P: n/a
Hi Nigel,

Yep, that worked great! Thanks so much for your help.

I still wonder why the TRY-CATCH block worked while in the VisualStudio
environment, but didn't in the standalone EXE. Since the threadexception
handler you suggested worked, this is sort of an academic question... But
for my general knowledge of VS and VB I sure would like to know why....
If anybody has the answer, please let me know...

Again, thanks,
John
"Nigel Armstrong" <ni****@newsgroups.nospam> wrote in message
news:5A**********************************@microsof t.com...
Hi John

Try adding this Event handler to your startup code:
AddHandler Application.ThreadException, AddressOf Bla

And then you will get unhandled exceptions in the Exception property of
your
ThreadExceptionEventArgs object.

Public Sub Bla(ByVal sender As Object, ByVal e As
System.Threading.ThreadExceptionEventArgs)

End Sub

HTH

Nigel

"JohnR" wrote:
Hi all. In my program I try to handle all obvious potential errors with
structured error handling (try-catch) block. What I would like to do is
have an 'overall' error handler that would gracefully catch any
unanticipated errors. I created a startup module to place my overall
error
handling for my "real" program which is Form1. My program is structured
like this:

Module startup

..

public sub Main()

.. try

.. application.run(new Form1) 'this is line 45 of module startup

..catch ex as exception

msgbox(ex.tostring)

end try

end sub

end module

Within the Form1 application I put a button that, when clicked, throws an
exception:

Button1Click

Throw new exception("error occurred") 'this is line 899 of Form1

Here's the problem. When I run inside the VisualStudio environment the
exception works exactly as I would expect. That is, my messagebox
displays
the full stack trace pointing to line 899 of form1 and 45 of startup.
Again, this is what I would expect.

However, when I build the appl and run it standalone, the same button
displays a popup window that says it is an unhandled exception, and does
not
give stack trace info.

Here's the good part.. if I put the "Throw new exception" into a
Try-Catch
block then when I run it standalone it DOES give me stack trace info.
So,
it seems like when I run it as a standalone exe the exception does not
"bubble up" to the next higher level of error handling as I think it
should.

Can anybody shed some light on this behavior? Thanks.

Nov 21 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.