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,
I have taken a look at the sample project that you have sent, and it appears that the Exception that you are throwing is being caught and is being shown in the output window, and this appears to be causing some interesting behavior internal to the XamDataTree, in that the code needed for the checkbox functionality is not able to run due to this exception being thrown.
I'm not sure of the functionality that you are hoping to see in this case, but perhaps you are looking to have your application break when this exception is thrown? If this is the case, I would recommend opening the Exception Settings in Visual Studio and make sure that you have the System.Exception set to true for the "Break When Thrown" field. By doing this, you should see that the application will break upon this exception being thrown.
Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate Developer
Hello Andrew,
Thank you for your answer. The showing of the exception in the output window is definitely not because the exception is caught by my code in the App file because there is a throw just after it and the application must crash, if that was the case.
You can easily test by commenting the code in the catch block and see that still the exception is being printed out in the output window which I guess Infragistics code is doing internally.
Yes I am looking for my application to break, when I am throwing an exception and not just in the DEBUG mode in visual studio! You can test it by running the EXE file and see that the application does not crash but the check boxes are not synchronized and the tree goes to an undefined state.
I have been looking into this issue with our development staff, and this exception appears to not be crashing the program as it is being caught by the BindingExpression class that is built into WPF. The BindingExpression class has a method named UpdateSource, and that appears to be where this exception is being caught, and so the application is not crashing. You can see this by checking the output window in Visual Studio in debug mode and throwing this exception. You should see a System.Windows.Data Error occur if you set your application to not break on the type of exception you are throwing.
Regarding derailing the checkbox functionality, this is expected when throwing an exception at the point that you are throwing it. This exception is essentially short-circuiting the logic that occurs internally that updates the parent or child nodes of the XamDataTree. Since the exception is interrupting the normal code execution path, the internal logic of the XamDataTree never really gets a chance to update the parent or child node's check state.
I am curious as to the functionality that you are really looking to achieve here, to be honest, as intentionally causing your application to crash is not usually a typical requirement. If there is some functionality that you are trying to prevent, why not add a message box or something of the like that informs the user of an invalid operation, rather than throwing an exception and derailing the XamDataTree's execution paths for its checkbox functionality, and then perhaps mark the application or the window that the XamDataTree exists in as closed?
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.
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.
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.
I found a solution to catch such exceptions in here: http://www.jasonbock.net/jb/News/Item/0f221e047de740ee90722b248933a28d
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.