Help with Debugging

[Jason Hunt]

I'm hoping someone can help me out with using the Visual Studio IDE for
debugging.

I'm working on a Windows Forms application (it's an MDI if it matters), and
I'm trying to fix a bug in my program. What's happening is
when the program is running, it runs into an exception error and switches
back to the Visio Studio screen. The problem is that it's not
showing me the line of code which actually caused the exception. Instead it
is showing the code for my startup form there is a green arrow
beside the "Public Class frmMain" line at the top of the code. How do I
have VS automatically jump to the line which caused the exception?

I've figured out where the problem is happening, by putting some breaks in.
I have a break before the line which is causing the exception
(this line is in the code of a different form, frmParts.vb, not frmMain.vb)
When it hits the break, it switches back to VS and highlights the
line with the break in frmParts. I press Step Into, it runs the line of
code, and then comes back to VS and highlights the next line in frmParts
(this is the line that's causing the exception). When I press Step Into
again, it runs the code, and comes back to VS with the dailog "An
unhandled exception of type 'System.ArgumentOutOfRangeException' occurred in
system.windows.forms.dll" That is fine, but now it's
highlighting the "Public Class frmMain" in frmMain.vb. I want it to be
highlighting the line which caused the exception, not the Public
Class line of the parent form.

In case it matters, the build type is set to "Debugging", not "Release"

Is there a problem with the way I'm trying to do debugging here? Please
keep in mind that I'm not asking for help with what's causing the
exception errors, I'm asking for help in the debugging process.

Any suggestions are appreicated.

[Jason Hunt]

Maybe I should also mention that the debugger used to act the way I wanted
it to (highlight the line that caused the exception upon breaking), but then
for some reason it started doing what I have described (green arrow) - so I
have a feeling it's an option somewhere maybe?

I looked through the MSDN library, and all I've been able to figure out is
that the green arrow has something to do with the call stack. I have no
clue what to do about it through.

[Oenone]

Jason Hunt wrote:

The problem is that it's not
showing me the line of code which actually caused the exception.

Do you have the IDE set to break on exceptions?

Select Debug>Exceptions from the menu, and select the "Common Language
Runtime Exceptions" item in the list. Then in the "When the exception is
thrown" box, select "Break into the debugger."

This will cause the code to break immediately any exception occurs, allowing
you to see exactly where it happened.

--

(O) e n o n e

[Charlie]

The green arrow just means that the error is happening on a line of code in
the block being called by the line that the green arrow is pointing to.

You could put a breakpoint where the green arrow is, re-run the code, and
use F11 to get to the called block. If you use Try blocks in all your
routines, and use the StackTrace property of the exception, you should be on
your way to resolving errors more quickly.

"Jason Hunt" wrote:

Maybe I should also mention that the debugger used to act the way I wanted
it to (highlight the line that caused the exception upon breaking), but then
for some reason it started doing what I have described (green arrow) - so I
have a feeling it's an option somewhere maybe?

I looked through the MSDN library, and all I've been able to figure out is
that the green arrow has something to do with the call stack. I have no
clue what to do about it through.

[Jason Hunt]

Hi Guys,

Thanks for the assistance. It turns out that what I described (green arrow
pointing to startup form instead of actual line of code) was only happening
when the exception was caused outside of the startup form's class. I have a
"business objects" class which does all the underlying work, and then the
forms for all the UI stuff which open instances of the business class. The
form was calling a function in the business class, and it there was a
missing bracket in an SQL query.

Charlies' suggestion of using Try/Catch narrowed it down.