3

What is the best way and why?

V1:

try
{
    var service = IoC.Resolve<IMyBLService>();
    service.Do();
}
catch(BLException ex)
{
   //Handle Exception
}

V2:

var service = IoC.Resolve<IMyBLService>();
var result = service.Do();
if (!result.Success)
{
   //Handle exception
}
Andy
  • 766
  • 1
  • 6
  • 16

2 Answers2

5

Exceptions are better in my opinion. I think that DDD code is first and foremost good object oriented code. And the debate about using exceptions vs return codes in OO languages is mostly over. In DDD context I see following benefits of using exceptions:

  • they force calling code to handle them. Exception don't let client code forget about the error. Calling code can simply forget to check for result.Success.

  • both throwing and handling code is more readable, natural and brief in my opinion. No 'ifs', no multiple return statements. No need to bend your Domain services to be exposed as 'operations'.

  • DDD in my opinion is all about using plain OO language to express specific business problems and keeping infrastructure out as much as possible. Creating 'OperationResult' class(es) seems too infrastructural and generic to me especially when language already supports exceptions.

  • Domain objects will throw exceptions anyway, even if its only for checking arguments. So it seems natural to use the same mechanism for domain services.

It may also be worth looking at the design itself, maybe there is a way to not get into error state in the first place? For example the whole class of 'validation' error conditions can be eliminated by using Value Objects instead of primitive strings and ints.

DDD is an approach, a set of guidelines so there is no 'right' way. The book never mentions this issue directly but the code in snippets and sample project use exceptions.

Dmitry
  • 17,078
  • 2
  • 44
  • 70
  • about "keeping infrastructure out as much as possible" - I wouldn't be as hard on that, for example Greg Young's CQRS heavily depends on the infrastructure with all events, commands, event store and rebuilding the aggregate and yet it is extremely focused on DDD. – kstaruch Aug 22 '11 at 08:17
  • Just because you can does not mean you should. If the language already has mechanisms for this. – Dmitry Aug 22 '11 at 15:37
  • I'm not stating that you should, I'm just saying that there are alternatives that might be more tailored to specific problem/context/requirements. My comment simply says that depending on pretty complex infrastructure is not always a bad thing and there's certainly more than one way to implement DDD. – kstaruch Aug 22 '11 at 23:40
  • What I like about V1 is that it gives you the ability to log any additional context regarding the error. Given the amount of complexity / code that's *probably* wrapped in the V1 example I think it's reasonable to not assume that it will always work. Also, good practice for error handling is to let errors bubble up to a top level handler - which would also justify V1 assuming that there wasn't anything "above" the try/catch in V1 (or similar in V2). – Adrian K Aug 23 '11 at 03:21
4

First of all, the IoC.Resolve<IMyBLService>() is actually a very bad usage of IoC container, you should inject your dependencies, not resolve them. I know that's not the point of the question, but it's worth mentioning.

As for Exception vs method result, it depends. The standard way to handle this is with Exceptions, however there are scenarios where it is cleaner and less cumbersome to return result instead. For example, I very often use operation results, because I have a very specific requirements for throwing non-domain related exceptions out of my SOA layer, so I would need to catch a domain-related exception just to create a new one. It wasn't logical, it wasn't readable, it affected performance, so we switched to results with a little bit of infrastructural sugar.

Another thing worth mentioning is that Exceptions tend to be a PITA when you need to run and return results of all your validation, without braking on first invalid rule.

kstaruch
  • 1,289
  • 7
  • 7