Weird exception catching

[Jarod]

Here is my problem:

 

Create a new windows application and add a new module:

Module Module1

 Public Sub main()
   Try
     Dim myForm As New Form1()
     myForm.ShowDialog()
   Catch
     MessageBox.Show("Exception caught")
   End Try
 End Sub

End Module

 

Now on the form add two textBoxes and add in form1 code:

 Private Sub TxtValidating(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles TextBox1.Validating
   Throw New Exception()
 End Sub

 

Modify the project property to start with the module

And now do some test:

- First click on TextBox1 and then click in TextBox 2

Validation will be called and you will see "Exception Caught"

- Second test : First click in TextBox1 and then TAB to TextBox2

validation will be done and you will see "JIT debugging......" in debug and in release mode

 

Why ? What's happening ?

[Nerseus]

First, I'm not sure what's happening. If you set a breakpoint on the "Throw New Excpeption()" line, you can check the call stack (Debug->Windows->Call Stack" to see what's going on. There are a bunch of different calls made so it's hard to see what's different.

 

But, the more important point might be to ask why you throw an exception during validation? Normally, that's a bad idea. The point of validation *should* be to check whether the data in the control is valid and set the CancelEventArgs.Cancel to true if it's not. If you really need a message to be displayed, I'd use a MessageBox or something else, but not an exception.

 

-Nerseus

[Jarod]

To answer you, of course I am not throwing an exception in my validation (not intentionaly). But in my development, I have to validate my data thru a web service and I receive an answer in a specific format. And for an unknown reason, I could receive something unexpected that may raise an exception at my side (waiting for an object and having a null reference for example)

 

As I saw that strange bahavior, I made a simple exemple where an exception is raised to see what's happening

 

And when looking at the stack Trace,I can see some differences but can't see why such a difference of behavior

[Nerseus]

Why not use try/catch in your validating event and simply set e.Cancel to true?

 

There's almost never a reason to NOT handle an exception and take a more appropriate action, especially in code where you're likely to get an exception (such as calling a webservice or taking user input).

 

-Nerseus

[Jarod]

Ok one point for you :)

 

However here is my point of view. I agree that you should catch any exception that may be raised during data input or web service calling.

However my approach is to have data input components with their own input validation via try / catch or not --> the user will only be able to enter valid data.

And for the Web Service, if any received data is not at the correct format, the application won't work properly and must be stopped until the problem is solved

But of course the program may not crash without a custom warning to the user (and to the admin)

And as a consequence, having a try/catch block at the higher level allow me to centralize the error treatment in this particular case and to stop the program

 

But in fact my question was not really about how avoiding this (many solutions : internal try / catch block as you suggest or even listening the events AppDomain.CurrentDomain.UnhandledException and Application.ThreadException at the higher level) but Why it is working like this ?

Why the JIT debugging is called (I haven't asked that via my config file) ?

Why only when using Tab Key and not for the mouse ?

[Jarod]

(for the web service, i was talking about problems due to server side coding... of course any problems like SoapException or WebException due to Authentication or network problems must be caught)

[Nerseus]

To be honest, I'm not sure of the difference. Looking at the Call stack, there's different internal .NET code running to fire the Validating event. Something in there isn't being caught or letting you catch it - I'm not sure which.

 

I've seen a similar problem when using DataBound controls. I had a grid control bound to a DataSet. During the changing of some data in the grid, I perform some validation and run through some fee calculation code. The fee calculation code might add/remove records from my dataset, which triggers another change event in my grid. Everything seems to work fine except there's an exception that I can't catch because it happens outside of any trappable code. By examining the callstack, I was able to figure out that the grid still had a reference to a row in my DataSet that was no longer valid since that row had been deleted somewhere down the line.

 

The point is this: in the above code, there was no place I could put a try/catch block to trap the error. But by using the call stack I could see what code was throwing the exception and then work on preventing the exception from happening in the first place. In your scenario, it seems likely that you could catch the exception at a higher level (in the validating event possibly) or even do manual checking of the data to prevent an exception.

 

Of course, if you feel that there's a bug in .NET that's causing the unhandled JIT error, you can always call MS support. If you have an MSDN subscription you get a free support call (maybe a few). Or, search http://support.microsoft.com for free. And there's always .NET 1.1 which just came out - you might try your sample code there, too, to see how it behaves.

 

-ner