As a Java developer, I am developing trying to use the clean code rules. But in my team we are facing a concrete problem:
We have a business layer offering a service called “createObject”, this service makes a lot of operation which can result to problem. E.g: parentObjectDontExist, objectAlreadyExist, dontHaveAuthorizationToCreate, operationFailed…
and we want the UI using this service to display different information messages depending which error occurred.
In old java dev, we should have create all signed exception type and throw it in createObject.
As Clean code says, it is forbidden to use Exception for business logic AND signed exceptions are evil…
Why not…But i don’t know how to solved this problem and i don’t want to use return code.
How do you do?
Thanks for youre experience return.
3
The answer is to use Callbacks
Create an interface that defines outputs of the system and instead of throwing an exception, call the right method from this interface. You may see it as “convert” one of your signed exception to a method in that interface.
This is also true for non-error “return” values. As you already know, you want to avoid exceptions and return values, in most* of your code. What you really want to do, is to have a callbacks, or multiple types of callbacks to use in order to pass the information to the proper handler.
That gives you the opportunity to create the proper handler that will implement your “error” interface and deal with the specifics of it.
(Same thing for “non-errors” paths!)
This will shape your code in a way that everything will be small, defined and extendable.(Read Single Responsibility Principle and Open Close principle from the SOLID principles, clean code, uncle Bob Martin.) By using the interfaces, you also comply to the L and D of the SOLID principles.. Better than that, if you have created the interfaces in a way that each one of them represents the method of one “domain”, one “client”, than, you also comply to I.
reminder:
S. Single Responsibility Principle
O. Open/Closed Principle
L. Liskov Substitution Principle
I. Interface Segregation Principle.
D. Dependency Inversion Principle.
- sometimes, it may happen to return a value and use an exception. The trick is to catch the “known” exception and use the callback methods of your output interface.
- Checked exceptions are not evil: sometimes they can be handy e.g. while writing a critical library. But in fact Runtime Exceptions are prefered in most scenarios.
- Define exceptions in terms of caller’s needs. Does the caller need to know about all the specific exceptions you mention here: parentObjectDontExist, objectAlreadyExist, dontHaveAuthorizationToCreate, operationFailed? If not, then it will be just enough to have one common exception type (e.g. CreatingObjectException) to be thrown by the service with a relevant information for the UI.
Clean code doesn’t say checked exceptions are evil or forbidden. It just says that in most scenarios they are a burden and it is not necessary to take it.
All your examples are exceptional cases that should not happen, because you defined preconditions and assume they are met. Uncle Bob meant exactly such a case when he said you should favor unchecked exceptions over checked ones.
Nobody says you are not allowed to catch (unchecked) exceptions. So, you may wrap your call in a try-catch block and show the error message, or, more elegant, handle it on a higher level (most UI frameworks have a built in exception handler that shows a generic message).