ExceptionValidationRule bug?

[jemidiah]

I'm trying to do some simple TextBox validation and found the ExceptionValidationRule class. My XAML is (basically)

<TextBox>
    <TextBox.Text>
        <Binding Path="MyText" UpdateSourceTrigger="PropertyChanged">
            <Binding.ValidationRules>
                <ExceptionValidationRule />
            </Binding.ValidationRules>
        </Binding>
    </TextBox.Text>
</TextBox>

and the MyText property is (basically)

public string MyText {
    get { return this.myText; }
    set {
        this.myText = value;
        if (!MyTextIsValid(value))
            throw new ApplicationException("Not valid.");
        else
            OnPropertyChanged("MyText"); } }

When run in debug mode, if I edit the text so that it becomes invalid, instead of just outlining the TextBox in red like I want, a debug window comes up saying the "Not valid." application exception was unhandled. When run outside of debug mode, it works properly.

I ran someone else's example code, though it wasn't written for VS2010. After running the upgrade wizard and the application, the same error appears. I also found a forum post which seems to describe my issue precisely, though it had no replies.

Since I've never used data validation before, I wanted to make sure I wasn't doing anything wrong and that this is indeed a bug. So, anybody have confirmation it's a bug or advice on what I'm doing wrong?


P.S. I'm aware there should be workarounds with the more complex validation techniques. I don't want to use them on principle, particularly since the non-debug version works fine.

[Lightning]

Turn of the "break on errors" option (Debug-->exceptions)

[jemidiah]

Thank you, that does prevent the error from getting raised. To be more specific, unchecking "User-unhandled" after finding "System.ApplicationException" prevents the error from being raised. I imagine I should define a custom exception class, add it to the list of exceptions in Debug->Exceptions, and uncheck user-unhandled for that exception, just to have zero impact.

For anybody reading this in the future, it seems there are several types of exceptions--(1) those handled by your code, (2) those handled by someone else's code (as in my case), and (3) those handled by nobody's code. With the default settings, most exceptions your code throws that fall into (2) will cause the debugger to break, even when an exception handler somewhere else is waiting to handle the exception. The Debug->Exceptions window controls what to do for cases (2) and (1), I believe.

There's another setting, Tools->Options->Debugging->General->Enable Just My Code (Managed only), which also prevents the debugger from raising the error. From the documentation, "When this feature is enabled, the debugger displays and steps into user code ("My Code") only, ignoring system code and other code that is optimized or that does not have debugging symbols. For more information, see How to: Step Into Just My Code." It doesn't really say how this setting changes exception handling, but it removes the "User-unhandled" checkboxes from Debug->Exceptions. My guess is that unchecking this option conflates cases (1) and (2) above.


So, it doesn't seem like a bug per-se, though it really should be mentioned prominently in the ExceptionValidationRule documentation. I assume there's a good reason VS treats user-code- and non-user-code-generated exceptions differently by default, which is the source of this mess in the first place....