Timeline for Error handling and exceptions in a layered (or onion) architecture
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 28, 2017 at 22:02 | comment | added | doubleYou | 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. | |
| Nov 28, 2017 at 20:51 | comment | added | Daniel T. | 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. | |
| Nov 28, 2017 at 17:32 | comment | added | doubleYou | 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. | |
| Nov 28, 2017 at 5:57 | comment | added | Flavius | 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. | |
| Nov 28, 2017 at 3:02 | history | answered | Daniel T. | CC BY-SA 3.0 |