This content originally appeared on Level Up Coding - Medium and was authored by Michał Grabowski
Exceptions have been introduced to handle errors on the function level. The intention was to avoid returning error codes and remove return type ambiguity. The power of exceptions comes from their ability to propagate through the stack downward. You are not obliged to handle exceptions directly. It allows you to separate your normal code flow from error handling.
An exception should be thrown when function assumptions about arguments are broken or if the function cannot fulfill its promise. The simplest example would be dividing by zero. We have to signal the caller that we can’t provide an answer. The exception constitutes part of the function contract. In linguistics, this is sometimes called presupposition failure. Consider the question if the king of France is bald. There is no king of France, so we cannot answer in terms of either yes or no. Any of those answers would be misleading.
Exceptions as part of the domain language
It is convenient to think about exceptions as part of the domain language itself. It is a great way to communicate. Business exceptions like OrderLimitExceeded are significant and informative. You get essential information on business expectations by flicking through the list of exceptions. It is necessary to build a consistent hierarchy of domain exceptions. For example, if your Order aggregate may raise many different exceptions as part of its API, all of them should extend a single exception like OrderException. It makes it easier to handle. The fact is that controlling exceptions flow is no easy task, and it requires a lot of discipline. Otherwise, it will get out of control sooner than later.
Problems with exceptions
Unfortunately, exceptions are not ideal. They disrupt the natural control flow of the code. It is GOTO in disguise. Using exceptions also adds complexity to the interface and enhances coupling. Throwing an exception breaks referential transparency, so our methods are not pure. Our function has no single return point, and that hinders reasoning substantially.
There is another massive issue with exceptions. Exceptions may lead to an inconsistent state of the model. If some operation can not be fulfilled, the model should remain in the same condition as before. Developers do not always pay attention to this. Offen exception is raised in the middle of computation where the model state has been only partially changed and is inconsistent. Neither your IDE nor compiler won’t help you with that issue.
A recent study shows that 90% of failures in distributed systems refer to incorrect error handling.
Functional approach
Using a monad-like container type like Option, Either, or Result is far more readable and elegant. Those are well-known constructs within functional-focused languages. We can design our API with a single return type in mind and don’t distort the control flow.
Order.addItem(Item $item): Either[Order, Error]
Adding an item may result in a new order (with that item) or an Error. Specifying what error types we may get from that method (OrderItemsNumberExceed, CanNotAddItemToFinishedOrder) is essential. The API is elegant and complete. Return type explicitly tells us we may not have a valid answer for any argument. We may use union types or generic OrderError and describe the errors in method documentation, but it is always better to depend on type-level safety.
It must be possible on a language level to easily sequence many calls without bothering about error handling. It is excellent when it is the case.
Option, Either, Result — types that retain monad characteristics are easily composable. This does not disrupt normal control flow or referential transparency. But without syntactic support on the language level might turn out to be cumbersome. Otherwise, exceptions may be far more attractive alternatives.
Disclaimer
This whole post refers only to the business domain environment and probably is not applicable in low-level or infrastructural circumstances.
Level Up Coding
Thanks for being a part of our community! More content in the Level Up Coding publication.
Follow: Twitter, LinkedIn, Newsletter
Level Up is transforming tech recruiting ➡️ Join our talent collective
Exception in Domain-Driven Design was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Michał Grabowski
Michał Grabowski | Sciencx (2022-07-05T12:17:41+00:00) Exception in Domain-Driven Design. Retrieved from https://www.scien.cx/2022/07/05/exception-in-domain-driven-design/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.