Info on unhandled exception during break mode, no exception variable?

[Samuel R. Neff]

When you have an unhandled exception in vb.net how do you view the
exception information in the debugger?

In C# the debugger creates a local variable that points to the
exception and you can view it in one of the windows (autos or locals,
don't remember which). That doesn't appear to be the case with
vb.net.

I also tried using the command window to inspect "Err" but that gave
nothing useful (always empty).

If I catch the exception then I have my own variable which has the
information, but that only applies to caught exceptions and I'd rather
not change my code to catch things lower down in the call stack just
to facilitate debugging.

Is there something I'm missing? A menu option? a window?

Thanks,

Sam

 

[Peter Huang [MSFT]]

Hi

Do you mean the $exception pseudovariable?

If so, it is unfortunate that VB.NET did not have the feature.

Based on the MSDN, we will know that that is for Visual C# only.

Note (Visual C# only) When an uncaught exception occurs, a pseudovariable
$exception is added to the Locals window. You can expand this
pseudovariable to see information on the exception.

Handling Exceptions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm
l/vctskHandlingExceptions.asp

A new pseudovariable $exception for retrieving information on C#
exceptions.

What's New in the Visual Studio .NET 2003 Debugger
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm
l/vxgrfwhatsnewinvisualstudionet2003debugger.asp

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Phill. W]

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...

Sub Main
Try
Application.Run( New Form1 )

Catch ex As Exception
. . .
End Try
End Sub

Regards,
Phill W.

 

[Jay B. Harlow [MVP - Outlook]]

Phill,

Sub Main
Try
Application.Run( New Form1 )

Catch ex As Exception
. . .
End Try
End Sub

Only catches exceptions that Form1's constructor throws.

To catch other unhandled exceptions 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/issues/04/06/NET/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.

Hope this helps
Jay

 

[Samuel R. Neff]

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

 

[Jay B. Harlow [MVP - Outlook]]

Samuel,

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.

#IF are not needed! you can use "Debug - Exceptions" in VS.NET to control if
exceptions (handled & unhandled) break into the debugger or get controlled
by your exception handlers.

By expanding the tree under "Exceptions" you can control the options for
individual exceptions.

By using the "Add..." button you can add your own custom exceptions to the
"Exceptions" tree.

For example if I have a Global Exception Handler I may change the "When the
exception is thrown" to "break into the debugger" when I want to "break
where the exception first occurs".

NOTE: "Debug - Exceptions" are useful for both Global Exception Handlers &
Try/Catch blocks in both VB.NET & C#.

Hope this helps
Jay