Debugger doesn't point out errors

[VBobCat]

I'm debugging my application, which is wrote in VB.NET
At one given point, I made a mistake: I created a DataTable and added a DataColumn with the same name of another DataColumn I already had added before.
At another point, I made something like this: I created a Dictionary(Of String, String) and added an entry with the same key of another entry I've previously added.
For my astonishment, I noticed that these errors are not indicated when running.
So I added this line to that routine:

Dim division_by_zero = 1 / 0

The result was the same. VS just drops execution pointer at the line the error occurs, without any warning. The application keeps running, that is, it keeps open and doing nothing.
Could someone explain what causes this bizarre behavior?
Thank you very much.

 

[jmcilhinney]

Is that code in the Load event handler of the main form? Are you on a 64-bit OS? If so then exceptions will be swallowed.

 

[VBobCat]

My computer's OS is Windows 7 64bit, although my application is not set to be 64bit-specific (in fact, I aim that the .exe runs solely and as widely as possible, regardless of OS and elevation privileges, to avoid deployment issues).
And the lost exceptions are not in Form.Load event handler itself. Some of them are in a chain of callings that starts there.
Most of them are not, however. But they are, indeed, in event handlers of a an object whose class is instantiated inside that Form.Load handler routine. Does it any difference?
This class gets Form's WebBrowser and deals with its events, and sometimes it raises its own events as consequence of WebBrowser events.
Now, is there a good reason for that happening, or is that a bug?
And if we can't avoid it, is there any detour?
I ask it, because that is the main form, the one which loads when application starts up, and it contains also the main interface, that is a WebBrowser control, which navigates the corporative intranet through a lot of web-based forms and services. Actually, automating this navigation, reading and writing data from these pages is the core feature of the applications.
That said, when the application starts up, it must do several things, but the main are:
- searching my data sources throughout a network, and connecting to them;
- loading the intranet's login.
These things are commanded from within Form.Load handler. But when user logs in, with his/her own username and password, the application, that is, a class made to do it, will catch WebBrowser's DocumentCompleted event, and do a series of tasks that user would otherwise need to do manually. Most of lost exceptions I noticed happen inside this WebBrowser.DocumentCompleted event handler, or inside routines called from there.
All that said, I can only say thank you very much for your advice... I've got sort of nervous trying to debug errors that don't halt the execution. That is way too much for my abilities...
Finally, if it is simply a bug of .NET, I wonder, will ever MS bother to solve it some day?
Thank you again!

 

[VBobCat]

I'm a bit ashamed, for I found that those errors that follow WebBrowser.DocumentCompleted event handler were dropped by my own fault.
As I said, I have this class, and it takes a WebBrowser when constructing, and then keeps handling its events. In some circumstances, the class' WebBrowser.DocumentCompleted event handler raises one event of its own. But this "RaiseEvent" statement was nested into a Try... Catch, and its exceptions were unhandled. Sorry. :apologetic:

But the issue with Form1.Load remains the same. I tried to transfer the statements inside this handler to a "Sub New" of this form. But then, all dependencies of this Form's Friend objects became problematic in other forms, for being references to non-shared members of the class Form1. Then I hat to settle down and roll back my changes, for there were hundreds of ocurrences of this error.

 

[JohnH]

But the issue with Form1.Load remains the same. I tried to transfer the statements inside this handler to a "Sub New" of this form.

There is no issue, no need to move code to different place. If statements in Load event handler can throw exceptions just Try-Catch those there.

And the lost exceptions are not in Form.Load event handler itself. Some of them are in a chain of callings that starts there.
Most of them are not, however. But they are, indeed, in event handlers of a an object whose class is instantiated inside that Form.Load handler routine. Does it any difference?

It is just calls in Load event handler that is relevant, event handlers of objects created there is not. Calls that may throw exceptions can be method calls (including object constructor) and use of properties.

 

[VBobCat]

Thanks. As I said, that issue about an object created in Form1.Load event was my own fault. Using F11, I found it.
If the debugger gets blind about exceptions inside Form1.Load handler, will "Try... Catch" groups inside it be able to see them?
I reduced the statements in this point to a minimum. Could I code into the Main() Sub instead, when creating Windows Forms Applications?
Thank you very much!

 

[jmcilhinney]

If initialisation code is specific to a form then it should be either in that form's constructor or in it's Load event handler or OnLoad method. Slow actions like file or database access should not be in a constructor. It's only unhandled exceptions that get swallowed on a 64-bit system and, while I'm not 100% sure, I think that it's only the startup form. If initialisation code is not specific to a form then it should go in the Startup event handler of the application.