Using IDataErrorInfo or any similar pattern for propagating error messages

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.

Answer 2

The members of the IDataErrorInfo interface typically have no meaning outside of the interface itself, because you hardly ever want to request the validation errors of a entity this way yourself. The IDataErrorInfo interface is meant to be consumed by UI technologies such as MVC and WPF.

Because there is no need to call the Error property or the this[string] directly the IDataErrorInfo members could typically be implemented explicitly. This prevents them from showing up on the class itself and allows you to implement your own -more useful- this[] indexer yourself.

I agree that having an indexer on that interface probably wasn't the best design, but IDataErrorInfo is probably designed with explicit implementation in mind anyway, so it doesn't really matter.

Here is an example of how to implement IDataErrorInfo explicitly.