The top level exception handler typically just displays a friendly
message and exits (or saves state if possible, or logs, or whatever).
Fine for production, not for development. I prefer to put these
handlers inside #IF conditionals so they aren't even in the debug code
base. In C#, this gives me an exception variable and breaks where the
exception first occurs. If I handle the exception at the top of the
application, then all errors will be caught there and the code will
break at the top. This will give me information about the error, but
not the state of the object that actually caused the error.
Really the "answer" as to whether there should be unhandled exceptions
in development code is not related to the original question--Does
VB.NET provide the same functionality as C# related to debugging
unhandled exceptions. Peter said No. That's unfortunate, but at
least can stop looking for an option.
Sam
On Fri, 10 Dec 2004 13:26:52 -0000, "Phill. W"
<P.A.Ward@o-p-e-n-.-a-c-.-u-k> wrote:
"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:m9********************************@4ax.com.. . When you have an unhandled exception in vb.net how do you view
the exception information in the debugger?
If an Exception is unhandled whilst you're developing, will it not
continue to be so when you release the finished Product? And, if it
does happen "out there", your users are going to be seeing some pretty
/horrible/, Framework-generated error dialogs.
I'd prefer to avoid /unhandled/ Exceptions altogether, even in Forms
applications...