Home > Java > A single simple rule for easier Exception hierarchy design

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!

email
Send to Kindle
Categories: Java Tags: ,
  1. Antoine CHAUVIN
    June 9th, 2014 at 19:27 | #1

    Who uses integers as exception descriptions anyway ?

  2. June 9th, 2014 at 19:51 | #2

    The integer is used as the code that appears in the stack trace as well as the key to the corresponding message property. Then, the message tells the user the code so he can mention it when he calls the call center.

    Yes, exception messages are not always for developers.

  3. Walter Laan
    June 10th, 2014 at 10:51 | #3

    @Nicolas Frankel
    The error code should be a constant (or an enum value), so you can find where it used by searching for references on that. You don’t really need a subclass (especially not 123 of them if there are that many error codes).

  4. June 10th, 2014 at 21:07 | #4

    Generally I agree with you in creating an own exception for every errorCode. I would prefer the usage of an enum value instead of int for the errorCode.

  5. tmszdmsk
    June 10th, 2014 at 23:10 | #5

    Anyway it won’t tell where this exception came from (if it’s thrown in more than one place). IMHO it would be better to display classname of exception or go deeper and put different “source id” in every place where exception is thrown.

  6. Damien CAROL
    June 11th, 2014 at 14:26 | #6

    Integers can provide localized message with CodeMessage table.

  1. No trackbacks yet.