/ DESIGN, EXCEPTION

A single simple rule for easier Exception hierarchy design

Each new project usually requires setting up an Exception hierarchy, usually always the same.

I will not go into details whether we should extend RuntimeException or directly Exception, or whether the hierarchy roots should be FunctionalException/TechnicalException or TransientException/PersistentException. Those will be rants for another time as my current problem is completely unrelated.

The situation is the following: when something bad happens deep in the call layer (i.e. an authentication failure from the authentication provider), a new FunctionalException is created with a known error code, say 123.

public class FunctionalException extends RuntimeException {

    private long errorCode;

    public FunctionalException(long errorCode) {
        this.errorCode = errorCode;
    }
    // Other constructors
}

At this point, there are some nice advantages to this approach: the error code can be both logged and shown to the user with an adequate error message.

The downside is in order to analyze where the authentication failure exception is effectively used in the code is completely impossible. As I’m stuck with the task of adding new features on this codebase, I must say this sucks big time. Dear readers, when you design an Exception hierarchy, please add the following:

public class AuthenticationFailureException extends FunctionalException {
    public AuthenticationFailureException() {
       super(123L);
 }
 // Other constructors
}

This is slightly more verbose, of course, but you’ll keep all aforementioned advantages as well as letting poor maintainers like me analyze code much less painlessly. Many thanks in advance!

Nicolas Fränkel

Nicolas Fränkel

Developer Advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). Usually working on Java/Java EE and Spring technologies, but with focused interests like Rich Internet Applications, Testing, CI/CD and DevOps. Currently working for Hazelcast. Also double as a teacher in universities and higher education schools, a trainer and triples as a book author.

Read More
A single simple rule for easier Exception hierarchy design
Share this