views:

328

answers:

2

I have a databound WPF CheckBox control that appears to be eating exceptions thrown by the corresponding property setter when the value is toggled in the UI. I know this can happen if I provide a ExceptionValidationRule on the Binding instance, but I double checked that the ValidationRules for the Binding instance has count zero. I also checked the call stack for intervening exception handlers and none exist. Nonetheless, the thrown exception does not bubble to the top and produce a crash in the app as I would expect.

If I throw an exception from a button click handler in the same UI, the exception does bubble up and cause an application crash, ruling out some sort of global exception handler.

Any ideas?

Thanks!

+1  A: 

No, this is expected behaviour: the WPF data binding infrastructure catches exceptions caused by saving the value from a binding target back to the source. I suspect this is because there is no way for the app to set up an exception handler around the save operation (because it is called from WPF code rather than from app code), so if WPF did not do this, the app would crash without the chance to handle the exception.

(By contrast, in a button click handler, you are writing the code so you do have the opportunity to handle exceptions. Therefore WPF thinks it's okay to let the exception propagate if you decide not to handle it.)

itowlson
+1  A: 

To add to itowlson's answer, the Binding class provides the UpdateSourceExceptionFilter property, which allows you to provide logic that runs when an exception occurs updating the source. It is used in conjunction with the ExceptionValidationRule class, and allows you to do something other than adding a ValidationError when the update fails.

HTH, Kent

Kent Boogaart