Does RadDateTimePicker swallow exceptions on SelectionChanged?

[Peter]

Hello,

consider the following xaml:

    <telerik:RadDateTimePicker SelectionChanged="RadDateTimePicker_OnSelectionChanged" />

In the code-behind, there's this:

    private void RadDateTimePicker_OnSelectionChanged(object sender, SelectionChangedEventArgs e)
    {
        throw new Exception("Exception!");
    }

Even if you add event handlers to the necessary events in App.xaml.cs (DispatcherUnhandledException and AppDomain.CurrentDomain.UnhandledException), these will never be triggered.

Do the same with a normal Button and the events will fire.

Is RadDateTimePicker(.SelectionChanged) swallowing these exceptions?

My application is a little more complex (with MVVM and a Command), but it boils down to that. So is there any way of catching these exceptions too? I want a general exception handler in my App.xaml.cs for any non-specific cases I didn't (or chose not to) handle. It would be cumbersome if I'd have to add try-catches for every command that's fired by a RadDateTimePicker (and a leaking of knowledge about the UI in my ViewModel).

[Konstantina]

Hi Peter,

This sounds very strange.
In the code there is nothing that we are doing particularly in removing the exceptions.
Could you please open a support ticket and send us a simple project where this can be observed. That will help in resolving the issue in a timely manner.

Looking forward to your reply.

Regards,
Konstantina
Telerik

 

 

[David]

Hi,

I have notice the same with the standard GridView SelectionChanged event. Any of these event handlers (DispatcherUnhandledException and AppDomain.CurrentDomain.UnhandledException) is never triggered.

They do however if the method becomes async.

[Peter]

For now, I've changed my code to use the event when the timepicker is closed (I think DropDownClosed). That works, but isn't complete as it won't fire if the user changes the datetime via the keyboard, so I need to catch that case as well.

[Konstantina]

Hello,

We have thoroughly researched the issue.
It turns out that the two way or the OneWayToSource bindings are swallowing the exceptions. This is default behavior of the framework. Can be found in the code of the UpdateSource method of the BindingExpression class:

if (CriticalExceptions.IsCriticalApplicationException(exception))
    {
        throw;
    }

Whre as critical application exception are considered:

if (ex is StackOverflowException || ex is OutOfMemoryException || ex is ThreadAbortException)
   {
      return true;
   }

This can be observed with a TextBox bound TwoWay or OneWayToSource to a property in which after PropertyChanged an exception is thrown. For example:

<TextBox Text="{Binding MyProperty, Mode=OneWayToSource}"/>

private string myVar;

public string MyProperty
{
   get { return myVar; }
   set { myVar = value;  this.OnPropertyChanged("MyProperty"); throw new NotImplementedException();  }
}

You could find more information also in this forum discussion: http://stackoverflow.com/questions/12658220/exceptions-thrown-during-a-set-operation-in-a-property-are-not-being-caught  

Hope this clarifies the matter.

Regards,
Konstantina
Telerik