8

Given an onion architecture, what are the advantages and disadvantages of throwing exceptions in the business logic (which is in the center of the onion) for invalid parameters provided by the user?

The alternative would be error codes.

I do have arguments for both approaches, exceptions vs. error codes, however I find it hard to decide.

Flavius
  • 257
  • 3
  • 12
  • see [What is the problem with “Pros and Cons”?](https://softwareengineering.meta.stackexchange.com/q/6758/31260) – gnat Nov 27 '17 at 14:12
  • Well, I'm not asking for tidbits of opinions, instead I'm asking for how to reach a good design decision. – Flavius Nov 27 '17 at 14:15
  • 1
    That is an even broader and less suitable question for this site. Such a decision must be reached by estimating how important each of these factors is *in your situation* and summing up the contrary influences. We don't know any of the properties of your situation, therefore the site cannot help you. – Kilian Foth Nov 27 '17 at 14:23
  • But the site could give me some trains of thought which I might follow in order to decide. I'm not asking for the decision, only for the way of thinking. – Flavius Nov 27 '17 at 14:27
  • 2
    Definitely relevant, not sure if it's a duplicate: [I've been told that Exceptions should only be used in exceptional cases. How do I know if my case is exceptional?](https://softwareengineering.stackexchange.com/q/184654/64132) – Dan Pichelman Nov 27 '17 at 15:31
  • @DanPichelman I've read it before asking but I'm still not sure about the specific case of exceptions inside the business model, the core of the onion. – Flavius Nov 27 '17 at 16:06

2 Answers2

4

The business layer should not be getting values provided by the user, invalid or otherwise. The application layer should have already validated the values and converted them from the application domain to the business domain.

To put it another way, an exception thrown from the business layer should not bounce all the way back to the UI layer. It should be caught by the application layer and converted into a useful UI element.

Daniel T.
  • 3,013
  • 19
  • 24
  • Oh yes, exactly this was my first reaction in favour of exceptions. The thing is: business rules are best validated in, well, the business. Otherwise I end up with validations spread around to places in the code where as a programmer you would not naturally expect them to be. – Flavius Nov 28 '17 at 05:57
  • Validation often has to happen at different points in an application, and a lot of it will have to happen in the business layer - otherwise, you'll often end up re-writing a good portion of the business code for validation. (See also https://softwareengineering.stackexchange.com/a/351662/278015). Where you have your validation logic doesn't influence whether to use Exceptions for validation failures, though. – doubleYou Nov 28 '17 at 17:32
  • Function parameter requirements *must* be met in order to call the function. If your business model has requirements that must be met then the application model must validate that those requirements are met *before* calling the business function as the contract requires. Regardless, exceptions should not be flying through the onion like a bullet, each layer should convert propagating exceptions into something the next layer understands. – Daniel T. Nov 28 '17 at 20:51
  • No disagreement here. Multiple layers play a role in validation and exceptions must be handled properly. What I was trying to say is that the reason for the exception (validation or not) or their source (business layer or not) do not change any of that - nor do they dictate whether to use exceptions in the first place. – doubleYou Nov 28 '17 at 22:02
2

There is a lot of material on SE and elsewhere dealing with Exceptions vs. Error Codes in general. There is nothing special about the business layer in this regard - try to handle errors as consistently as possible throughout the application.

So if you would use an Exception for validation errors in other parts of your application, do the same here.

doubleYou
  • 2,737
  • 1
  • 11
  • 25