Question

I apologise for this question as it is rather fuzzy and there are several questions integrated but as they are so closely related I did not want to break them apart into several submissions.

I am currently thinking about how to test for configuration errors in an application. There are different options available and one which has been used before is the IDataErrorInfo interface. I am not extremely happy with how this implementation looks, not because it doesn’t work because it do, just that I don’t fully agree with the actual implementation. I have been searching around this site (all 52 related questions) and others to see why Microsoft decided that using the keyword “this” with a index would be a good idea. It is typically used for indexing items in a collection, and even tough one could consider the classes I implement as a collection of errors I do not really agree with that the “this[]” keyword should implicitly be used for testing for them. (Side note: Does this mean that a custom collection class cannot have configuration errors of its own?) Why is this not a method call like “TestErrorState( string propertyname )” or even an indexed a property? And how often is the “string Error { get; }” actually used? To me it looks like kind of a “hack” and not really easy to use.

One of the practical issues I do have due to this implementation is that I have objects relating to other objects and I would like the error states to propagate. This turns out ugly as the class which is on display in the user interface should be in an “error state” due to a related object which is not necessarily shown to the user (unless the user clicks an option on the interface and moves “down” one level in the hierarchy of objects). This means that I need to extend the test for error modes with my own methods for propagating these errors and then I start questioning whether I should just implement something completely different and not go for the IDataErrorInfo interface at all.

Please let me know where I can find some good information about why IDataErrorInfo is the way it is. And if you can provide me with a nice idea for how to have error modes that propagate through a hierarchy of objects that would be just brilliant! When I say propagate I don’t mean as an exception as this feels like an event, it is just that when an object is asked for configuration errors it should also ask all its children for errors and then pass on also the children’s error messages.

Answer 1

I am not sure if you are using MVVM but it looks like it. I agree that this[] puts extra unnecessary constraint on the implementation while it could have been a GetError(string propetyName). I think this is a COM hangover and this interface is exposed through COM but will check and confirm.

In practice, I have never found this[] causing any problem. This would almost never be implemented to collection since binding for collections would usually use ObservableCollection and only individual items will implemented IDataErrorInfo.

If you have a hierarchy (e.g. Customer and Orders), you would typically implement a view model for both and order view model would have a reference to its parent customer view model so that it can propagate the error. Scenarios I have had, this approach always worked. If you have a specific problem, post a new question or update yours.