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 ? Whats happening ?

 

[Nerseus]

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

But, the more important point might be to ask why you throw an exception during validation? Normally, thats 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 its not. If you really need a message to be displayed, Id 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 whats happening

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

 

[Nerseus]

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

Theres almost never a reason to NOT handle an exception and take a more appropriate action, especially in code where youre 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 wont 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 havent 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, Im not sure of the difference. Looking at the Call stack, theres different internal .NET code running to fire the Validating event. Something in there isnt being caught or letting you catch it - Im not sure which.

Ive 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 theres an exception that I cant 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 theres a bug in .NET thats 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 theres always .NET 1.1 which just came out - you might try your sample code there, too, to see how it behaves.

-ner