Exception handling problems in Java, Part I

Author: Kasper B. Graversen, 23/05/08 Keywords: Exception handling, Refactoring, Java Abstract: Java's type system has a serious flaw. It does not allow refactoring common exception handling code into methods. This article will show the meaty juicy details of the problem.

subscribe to my RSS feed

Exception handling problems in Java, Part I

Method inspectClassForSetMethods_old(final Object destinationObject, final Class variableType, final String variableName) {
    final String methodName = "set" + variableName.substring(0, 1).toUpperCase() + variableName.substring(1);

    try {
        return destinationObject.getClass().getMethod(methodName, variableType);
    }
    catch(SecurityException e) {
        e.printStackTrace();
        throw new RuntimeException(String.format("Can't find method '%s(%s)' in class '%s'. "
            + "Is the name correctly spelled in the NameMapping? "
            + "Have you forgot to convert the data so that a wrong set method is called?", methodName, variableType,
            destinationObject.getClass().getName()), e);
    }
    catch(NoSuchMethodException e) {
        // retry again due to autoboxing in java we need to try both cases
        try {
            if( autoboxingConverter.containsKey(variableType) == false ) {
                e.printStackTrace();
                throw new RuntimeException(String.format("Can't find method '%s(%s)' in class '%s'. "
                    + "Is the name correctly spelled in the NameMapping? "
                    + "Have you forgot to convert the data so that a wrong set method is called?", methodName,
                    variableType, destinationObject.getClass().getName()), e);
            }
            return destinationObject.getClass().getMethod(methodName, autoboxingConverter.get(variableType));
        }
        catch(SecurityException e1) {
            e.printStackTrace();
            throw new RuntimeException(String.format("Can't find method '%s(%s)' in class '%s'. "
                + "Is the name correctly spelled in the NameMapping? "
                + "Have you forgot to convert the data so that a wrong set method is called?", methodName,
                variableType, destinationObject.getClass().getName()), e);
        }
        catch(NoSuchMethodException e1) {
            e.printStackTrace();
            throw new RuntimeException(String.format("Can't find method '%s(%s)' in class '%s'. "
                + "Is the name correctly spelled in the NameMapping? "
                + "Have you forgot to convert the data so that a wrong set method is called?", methodName,
                variableType, destinationObject.getClass().getName()), e);
        }
    }
    // return null; // compiler error "unreachable code"

1. The business logic of the code is drowning in exception handling code. Focus is easily lost.
2. There is quite a lot of code duplication in the code. Essentially all the catch blocks are identical. This calls for a simple refactoring, Extract method to the rescue! (more on this!)
3. The last statement in the code is outcommented (return null;). The compiler prevents the existence of that statement by throwing a "unreachable code" error at compile time.

Method inspectClassForSetMethods(final Object destinationObject, final Class variableType, final String variableName) {
    final String methodName = "set" + variableName.substring(0, 1).toUpperCase() + variableName.substring(1);

    try {
        return destinationObject.getClass().getMethod(methodName, variableType);
    }
    catch(SecurityException e) {
        throwException(destinationObject, variableType, methodName, e);
    }
    catch(NoSuchMethodException e) {
        // retry again due to autoboxing in java we need to try both cases
        try {
            if( autoboxingConverter.containsKey(variableType) == false ) {
                throwException(destinationObject, variableType, methodName, e);
            }
            return destinationObject.getClass().getMethod(methodName, autoboxingConverter.get(variableType));
        }
        catch(SecurityException e1) {
            throwException(destinationObject, variableType, methodName, e1);
        }
        catch(NoSuchMethodException e1) {
            throwException(destinationObject, variableType, methodName, e1);
        }
    }
    return null; // Can never be reached.. but the compiler requires it!!
}
/** Confining exception handling code. Must always throw an exception */
private final void throwException(final Object destinationObject, final Class variableType, final String methodName,
    Exception e) throws RuntimeException {
            e.printStackTrace();
            throw new RuntimeException(String.format("Can't find method '%s(%s)' in class '%s'. "
                + "Is the name correctly spelled in the NameMapping? "
                + "Have you forgot to convert the data so that a wrong set method is called?", methodName,
                variableType, destinationObject.getClass().getName()), e);
    }
}

More problems

Solutions

    } catch (Exception1 ex) {
       ..
        throw ex;
    } catch (Exception2 ex) {
        ..
        throw ex;
    }

    } catch (Exception1 | Exception2 ex) {
        ..
        throw ex;
    }

• You can confine exception handling business logic in one part of the application and ensure consistency across the whole application
• My idea does not require new syntax or learning something new. In fact, it not working is the puzzling part which goes against all rules for good language design and "least surprise for the user".
• In the multiple catch example, every programmer needs to learn yet another rule. And I have trouble understanding why it the the bit operator OR that separates the exception types, why not use the logical or, it's a much better choice! Then, at least, the syntax and semantics are consistent and syntactically in line with 99.99% of all if statements you probably ever will type.

Comments

Help spread the word