views:

36

answers:

2

Hi all,

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.

+1  A: 

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.

Aliostad
Thank you for a prompt response! I agree that the “this”-thing don’t pose any practical issues; it’s more that I don’t really see the point and think it looks kind of bad.
Mikael
I agree with the view model for both objects, however, how will this look in practice? This means that the parent will use the IDataErrorInfo interface of it’s ”children” and, using reflection, ask each property. Or should one implement a method, e.g. “GetErrors”, in the children that goes through all its own properties looking for errors and returns some custom struct/class? The fact that the “this[]” call only returns the error message and not a more rich data structure makes it a bit difficult (in my mind) when error messages are to be propagated.
Mikael
No, parent will expose (through an interface and children will use that interface) a method (not IDataErrorInfo's this[] of course) such as UpdateError() to communicate with the parent view model and update the error information.
Aliostad
Yeah, I get your point and this is how I envisioned that it should be done. My only problem is that I seem to be moving away from the idea of IDataErrorInfo and into a custom implementation. But on the other hand this is not a real problem, it could just be me trying to misuse the interface to start with. Thanks for your input!
Mikael