0

Occasionally, I get errors such as System.Windows.Data Error: x due to exceptions being thrown inside the getter and setter of view model properties bound to XAML.

Problem

When exceptions are thrown inside these setters and getters, some of those exceptions may contain useful information in their Data properties. Ideally, no exceptions should be thrown inside getters and setters, but the project is fairly large at this point and rewrites would be a tremendous task. My debugging would be much better if I could be able to access the exception data.

What I have done

I have set up a simple TraceListener which is added to PresentationTraceSources.DataBindingSource. This listener constructs the stack trace and reports this to my bug reporter service.

However, the strings that are provided to this listener do not contain the exception data, i.e. Exception.Data, which is my preferred way to attach additional information to an exception. I could change all my exceptions to add this information to the exception message, but that will create large exception messages and I think it is wrong use of the Exception class.

Question

How can get the original exception that is thrown from XAML binding errors so that I may access the exception data and all inner exceptions in order to create better bug descriptions? Or is it another way to access this data?

Any insight on this issue is highly appreciated.

Thomas Angeland
  • 441
  • 5
  • 10
  • If your exceptions are thrown from inside the getter and setter of properties, then they are not binding errors. Binding errors are displayed in VS Debug output. Did you try adding try catch block in ViewModel code that actually changes the value of those properties? – o_w Jan 14 '21 at 09:42
  • @o_w It is a System.Windows.Data Error; sorry if I used the wrong term for it. Sure, I could add a a try-catch to this specific issue and get the exception object that way, but I am looking for a general solution that will work for my entire code base (of thousands of lines of code). Adding a try-catch to all complex properties would be a lot of work and a lot of boilerplate code. – Thomas Angeland Jan 17 '21 at 00:02
  • I didn't mean to place the try catch block inside the setters, I meant to place it in the methods that cause changes to your properties. Regarding catching the exception: https://stackoverflow.com/a/46804709/13163025 – o_w Jan 17 '21 at 07:45

0 Answers0