How Do I Debug a Class Constructor?

  • Thread starter Thread starter TC
  • Start date Start date
T

TC

I asked this question before, but didn't receive an answer, so I'll
try again.

When I get a runtime error in Debug mode, Visual Studio highlights the
line where the error occurred, then let's me debug the error and
resume execution. This is extremely useful. However, this feature
doesn't seem to work when the runtime error occurs in a class
constructor (Sub New). In that case, Visual Studio does not show me
the line which generated the error, and I have to dig into the
InnerException to learn anything about what happened. This can make
debugging extremely frustrating.

In response to this behavior, I've learned to structure my code in a
way that avoids use of Sub New. However, I feel like that may be a
mistake. Therefore, I'd like to look more closely at this issue and
figure out exactly what is going on. I'd be grateful if anyone can
help me answer the following questions:

- First of all, are other people seeing the same thing, or is it just
me?

- Second, is this behavior documented or explained somewhere?

- Third, can I customize this behavior at all? Can I, for instance,
change a setting or add a compiler instruction to make the debugger
work the way I want?


-TC
 
I asked this question before, but didn't receive an answer, so I'll
try again.

When I get a runtime error in Debug mode, Visual Studio highlights the
line where the error occurred, then let's me debug the error and
resume execution. This is extremely useful. However, this feature
doesn't seem to work when the runtime error occurs in a class
constructor (Sub New). In that case, Visual Studio does not show me
the line which generated the error, and I have to dig into the
InnerException to learn anything about what happened. This can make
debugging extremely frustrating.

In response to this behavior, I've learned to structure my code in a
way that avoids use of Sub New. However, I feel like that may be a
mistake. Therefore, I'd like to look more closely at this issue and
figure out exactly what is going on. I'd be grateful if anyone can
help me answer the following questions:

- First of all, are other people seeing the same thing, or is it just
me?

- Second, is this behavior documented or explained somewhere?

- Third, can I customize this behavior at all? Can I, for instance,
change a setting or add a compiler instruction to make the debugger
work the way I want?
Click to expand...

I am almost positive I have seen runtime errors in a class
constructor.

But class constructors provide a very useful purpose. It is the
recommended place to initialize all local class variables. Also, the
overloading feature is very useful.

Have you tried to put a breakpoint in the constructor?
 
Are you breaking on all exceptions?
By default the debugger only stops on unhandled exceptions.

Sounds like you might me catching some exceptions...

Also note the constructor is not always called, depending on what you are
doing:
http://msdn2.microsoft.com/en-us/library/ms973893.aspx

Schneider

I asked this question before, but didn't receive an answer, so I'll
try again.

When I get a runtime error in Debug mode, Visual Studio highlights the
line where the error occurred, then let's me debug the error and
resume execution. This is extremely useful. However, this feature
doesn't seem to work when the runtime error occurs in a class
constructor (Sub New). In that case, Visual Studio does not show me
the line which generated the error, and I have to dig into the
InnerException to learn anything about what happened. This can make
debugging extremely frustrating.

In response to this behavior, I've learned to structure my code in a
way that avoids use of Sub New. However, I feel like that may be a
mistake. Therefore, I'd like to look more closely at this issue and
figure out exactly what is going on. I'd be grateful if anyone can
help me answer the following questions:

- First of all, are other people seeing the same thing, or is it just
me?

- Second, is this behavior documented or explained somewhere?

- Third, can I customize this behavior at all? Can I, for instance,
change a setting or add a compiler instruction to make the debugger
work the way I want?
Click to expand...

I am almost positive I have seen runtime errors in a class
constructor.

But class constructors provide a very useful purpose. It is the
recommended place to initialize all local class variables. Also, the
overloading feature is very useful.

Have you tried to put a breakpoint in the constructor?
 
I asked this question before, but didn't receive an answer, so I'll
try again.

When I get a runtime error in Debug mode, Visual Studio highlights the
line where the error occurred, then let's me debug the error and
resume execution. This is extremely useful. However, this feature
doesn't seem to work when the runtime error occurs in a class
constructor (Sub New). In that case, Visual Studio does not show me
the line which generated the error, and I have to dig into the
InnerException to learn anything about what happened. This can make
debugging extremely frustrating.

In response to this behavior, I've learned to structure my code in a
way that avoids use of Sub New. However, I feel like that may be a
mistake. Therefore, I'd like to look more closely at this issue and
figure out exactly what is going on. I'd be grateful if anyone can
help me answer the following questions:

- First of all, are other people seeing the same thing, or is it just
me?

- Second, is this behavior documented or explained somewhere?

- Third, can I customize this behavior at all? Can I, for instance,
change a setting or add a compiler instruction to make the debugger
work the way I want?

-TC
Click to expand...

Are we talking about an object that has a designer attached? (Such as
a form or control).

If so, then the InitializeComponent method of the form (or control)
will be bypassed when debugging by default with the
<System.Diagnostic.DebuggerStepThrough()> attribute. Commenting out
this attribute will allow you to step through the InitializeComponent
method.
 
Are we talking about an object that has a designer attached? (Such as
a form or control).

If so, then the InitializeComponent method of the form (or control)
will be bypassed when debugging by default with the
<System.Diagnostic.DebuggerStepThrough()> attribute. Commenting out
this attribute will allow you to step through the InitializeComponent
method.- Hide quoted text -

- Show quoted text -
Click to expand...

Thanks to everyone for the replies. Judging from the responses, it was
clear that I was describing something unusual, so I did some more
research. I found that the problem doesn't really have anything to do
with Sub New. Instead, it occurs because I was using a form as the
startup object.

Specifically: When I use a form as the startup object, all code which
runs during the initialization of that form is subject to the limited
debugging behavior I described. (Most of that code is class
initialization; that's why I originally thought the problem applied
only to Sub New.) When I stop using a form as the startup object, and
use Sub Main instead, debugging works fine.

Conclusion: Never use a form as the startup object. Always use Sub
New.

Problem solved. Thanks for the help.


-TC
 
TC,

As almost everybody using VB for net forlong times has once used a form as a
startup object and have no troubles with that, does that mean that you are
the guy/girl can write.

Maybe your problem is solved however probably you have fixed something else,
that you did not recognize, this is not the reason that the debugger was
stepping through the code.

Just to beware some read your text on message and get the idea that your one
time investigation is true.

-TC
 
Specifically: When I use a form as the startup object, all code which
runs during the initialization of that form is subject to the limited
debugging behavior I described. (Most of that code is class
Click to expand...

Did you try removing the <System.Diagnostic.DebuggerStepThrough()>
attribute from the form as Inictus indicated? I think that is the
source of your trouble.

Chris
 
Well... I was satisfied with my conclusion, but it looks like there is
dissent, so I'll follow this thread a little further. I've posted a
simple solution to illustrate the issue. <ftp://MatsonConsulting.com/
DebugTest.zip> The code generates a runtime error in MainForm's class
construtor. When I change the startup object back and forth between
MainForm and Sub Main, I get different debugging behavior. The
debugging behavior I get with Sub Main is clearly preferable. I'm
curious to know if you guys see the same behavior when you run the
code.

In my current work, this is a significant problem because the MainForm
constructor initializes many other objects, running hundreds of lines
of buggy code. Before I switched to Sub Main, debugging was a
nightmare. I'd be glad to find that this is a known issue with a best
practice solution, even if that solution is different than mine; until
then, however, I'm satisfied to adopt a policy of avoiding startup
forms in favor of Sub Main.

Also: Thanks for the advice Chris, but I don't think this issue has
anything to do with DebuggerStepThrough. I've noticed that Visual
Studio sometimes puts that instruction in Application.Designer.vb.
However, debug behavior isn't quite right even when that instruction
is omitted.


-TC
 
Steve,

That is a complete different issue, however has nothing that has to do with
Sum Main, as TC is keeping telling as a known issue, or it should be by
somebody as Andersen?

Cor
 
Back
Top