 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / VB.NET / March 2008How Do I Debug a Class 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 > I asked this question before, but didn't receive an answer, so I'll > try again. [quoted text clipped - 22 lines] > change a setting or add a compiler instruction to make the debugger > work the way I want? 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 On Mar 26, 1:49 pm, TC <golemdan...@yahoo.com> wrote: > I asked this question before, but didn't receive an answer, so I'll > try again. [quoted text clipped - 22 lines] > change a setting or add a compiler instruction to make the debugger > work the way I want? 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. [quoted text clipped - 24 lines] > > -TC 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. > > I asked this question before, but didn't receive an answer, so I'll > > try again. [quoted text clipped - 35 lines] > > - Show quoted text - 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. >>Conclusion: Never use a form as the startup object. Always use Sub New. 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 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 > 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 [quoted text clipped - 19 lines] > However, debug behavior isn't quite right even when that instruction > is omitted. I found something vaguely related when I had a Splash form as startup, and then a main form. The splash seemed to run on a separate thread, and that cause various issues. This is with the app framework, or whatever its called, activated. I ended up with my main form as the startup, but with a lot of loading and startup code in the app start event, which first shows the splash, then does all the foo. The main form just closes the splash. 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
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.