Hello,
I am experiencing a behavior which I think is because there is an exception handling inside of Infragstics code which is wrong and not communicated.
I am not sure whether I am missing something or this is a bug or wrong exception handling.
Reproducing is very simple:
Just define a Data Tree with the check boxes feature and define the NodeCheckedChanged event and throw an exception inside it. You will see that it will not bubble up from the event.
I also attached an example. I am not sure whether what I am doing inside of App is correct but you can compile and run exe file to see that nothing is thrown and the application goes to an undefined state.
Hello Arash,
Thank you for your update. I am glad you were able to find a way to catch the BindingExpression exceptions that are being thrown in this case.
Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate Developer
I found a solution to catch such exceptions in here: http://www.jasonbock.net/jb/News/Item/0f221e047de740ee90722b248933a28d
Hello Andrew,
Thank you for your answer. However, this is not the answer which I was looking for. The exception is thrown from the binding expression because Infragistics "internally tries to update the checked status of the other XamDataTreeNode checkboxes". It is not the case where WPF always throw an exception when an exception is thrown in the events, it is because Infragistics is performing an operation in WPF which is not correct and WPF throws an exception and handles it. Maybe the way that the checked status of the other nodes are set is not the correct way.
Sincerely,
Arash
I apologize, but nothing in the Infragistics code base is actually catching this exception. This exception is being caught by the System.Windows.Data.BindingExpression class because the NodeCheckedChanged event internally tries to update the checked status of the other XamDataTreeNode checkboxes, and this exception is derailing that update for the BindingExpression. The BindingExpression is catching the exception and is preventing the application from crashing, and in debug mode, you see a System.Windows.Data error in the output window of Visual Studio as a result. Unfortunately, this is not really something we can change.
If you have a reason to throw an error in the NodeCheckedChanged event of the XamDataTree, I would recommend that you show your user a MessageBox or something of the like, as this will allow you to notify them that something has gone wrong and that the application will close. You can then manually mark your application as closed, as the exceptions will continue to be handled by the BindingExpression class for this particular event of the XamDataTree.
Regarding your attached sample project, I understand your concerns that the NodeCheckedChanged event is not producing the same behavior as the Checked event of the built-in Checkbox, but these two events are working very differently. For example, the Checked event of the checkbox is not attempting to update other checkboxes based on its checked status, but the one in the XamDataTree is. This is why the exception gets handled by the BindingExpression class in the case of the XamDataTree, as there is a BindingExpression that is updated by this NodeCheckedChanged event.
Yes I suspected that something inside of Infragistics code is catching this exception. What I am trying is to achieve is the robustness of my application, when an error occurs. When an error occurs, I want to make sure that the application does not continue and inform the user. Definitely my logic would not be throwing an exception directly but a code is executed by the trigger of changing the check box which will be throwing exception. This is not for the user input verification. The behavior which I am looking for is the definition of an exception to be able to bubble-up to be able to take the required decisions or stop the application.When an error happens, I do not want the user to continue working with the application and see that the check box states are not updated and in fact, even that is not the issue. The issue is because somewhere there is an exception which is thrown but handled and the code is continuing without performing the required action.
Your question basically is why I need an exception to be thrown and bubble up and the famous practice: "Throw early, catch late." You can find many articles why this is necessary.
I attached a new modified sample. I think it is better to understand what I am looking for by comparing the behavior of the WPF check box and Infragistics Tree check box.
I am looking for to be able to understand that my application crashed and not in a correct state.