4

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.

closed as too broad by gnat, 8bittree, BobDalgleish, Christophe, Andres F. Dec 8 '17 at 16:41

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

2

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.

  • 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 5: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 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
1

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.

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