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.

  • 2
    You don't want to use Exceptions to propagate information, but you don't want to use return values either? I'm afraid the only other way is to generate side effects, which is worse than either option. Oct 30, 2013 at 14:00
  • 2
    Why is it forbidden to use Exceptions for 'exceptional' circumstances in Business Logic? Do you have any reference?
    – jbx
    Oct 30, 2013 at 14:00
  • 2
    Darn those pesky error conditions and invalid data problems. They seem to ruin everybody's utopian design methodology:)
    – Dunk
    Oct 30, 2013 at 14:15

3 Answers 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.


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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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