1

I have some context
then I can do:
with context.getError(Object): ErrorHolder

holder.addError(error)

OR

context.setError(Object, error)

setError will probably have this implementation:
context.getError(Object).addError(error)

what approach should I choose and why?

Improve this question
4
  • 2
    Always choose the one that will cause you least amount of effort and grief in future. Its really hard to tell which one because we don't know what your code does. Can you elaborate on the use case of the context and the errors?
    – Tjaart
    Oct 25, 2012 at 7:23
  • @Tjaart The context is created when user entered values and pushed them into an application. I'm setting values user entered to those objects inside the context and If I see a wrong value, I add an error to the context, so when context will try to persist objects, he will instead notify user that bad value is entered.
    – dhblah
    Oct 25, 2012 at 7:27
  • 1
    So you are storing a collection of validation errors, matched with which object failed to validate, in the context?
    – Tjaart
    Oct 25, 2012 at 7:41
  • Yes that's right.
    – dhblah
    Oct 25, 2012 at 7:51

3 Answers 3

Reset to default
1

I would definitely go with the second method. Why?

Well it seems to be the simplest answer. In the first instance it will require two calls everytime you need to add or get an error from your context.

There is another alternative, provided that you are providing your Object classes and they are not generated by some 3rd party lib.

You can add an ErrorCollection property to the base class of your data objects that keeps errors. That way when your object moves around the errors are linked with it.

That way you will have

object.addError()
object.getError(index)

This is cleaner because you are not maintaining objects and a relation of objects to their errors.

Improve this answer
3
  • Maybe I didn't understood you correctly, but I don't want to add errors to objects itself. Objects only contains some business - date, not their validation data. That's why I'm keeping all validation data inside the context.
    – dhblah
    Oct 25, 2012 at 9:07
  • @johnsmithoptional then you can go with the second method that you mentioned as I said. Why don't you want to keep the error data in a base class of the data objects though?
    – Tjaart
    Oct 25, 2012 at 9:09
  • 1
    because it doesn't belong there. The validation info is a technical information and objects themselves contain only business-specific data.
    – dhblah
    Oct 25, 2012 at 9:55
3

Isn't this a case where you would be 'violating' the Law of Demeter ?

The second one, provided you use a name like context.addError(object, error) if you can actually have several errors on an object, hides ErrorHandler to the clients of context. Is ErrorHandler an implementation detail, or could clients of 'context' use it too ?

Improve this answer
1
  • note: context.addError should have error as a parameter. ErrorHandler can be used by clients.
    – dhblah
    Oct 25, 2012 at 9:04
1

I'm a fan of keeping things simple. This enhances readability and the usability of an API. I don't think there's a definitive answer, But I would go for the second approach, although I would call the method context.addError(object, error), for this implies, that their could be more than one error, which is the case, when I look at your possible implementation.

The getError(object)-approach lacks good naming too, I think. If you choose the first approach consider naming the Method getErrorHolder(object).getError().

EDIT: If I still get you wrong, that's a sign for ambigious naming. Use add for adding to a Collection and set for single instances.

Improve this answer
2
  • there is a couple of objects in the context, so I should specify for which object to add an error.
    – dhblah
    Oct 25, 2012 at 7:21
  • Excuse me, I mixed things up a little bit. I'll correct it in my answer. The principle stays the same: focus on readability, expressiveness and usability of the API.
    – Regular John
    Oct 25, 2012 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.