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!