Approaches to catching and propagating Exceptions in Java Servlet Programming

Approaches to catching and propagating Exceptions in Java Servlet Programming.*

1. Do nothing and hope it goes away.

catch (SQLException e)

{
}

OK, this is very dumb and pretty much anyone who knows a bit of Java should know better. Don’t do it.

2. Log it and still hope it goes away.

catch (SQLException e)

{
log.error("Found an exception, now what do I do?");
}

Not much of an improvement on 1, but at least if someone bothers to look at the logs they’ll find out.

3. Log it with the stack trace, then hope it goes away.

catch (SQLException e)

{
log.error("Found a SQLException", e);
}

Slightly better, at least the log files will have a stack trace, if someone bothers to look at the logs that is.

4. Rethrow it as a ServletException.

catch (SQLException e)

{
throw new ServletException("Found a SQLException");
}

This is much better, now the Servlet’s error mechanism (you do have one right?) can kick in and do clever things like send out an error email and display a fancy error page to the user etc. Still something missing though.

5. Rethrow it as a ServletException, passing along the root cause.

catch (SQLException e)

{
throw new ServletException("Found a SQLException", e);
}

ServletExceptions can accept an Exception in their constructor and “wrap” it (all Exception types in JDK 1.4 allow this also).

Now the error email can drill down into the ServletException’s root cause and display the actual SQLException stack trace, which should give a pretty good indication of the original error.

6. Rethrow it as a ServletException, passing along the root cause but with no message.

catch (SQLException e)

{
throw new ServletException(e);
}

Minor variation on 5, remove the message stating a SQLException was found, it adds no information to what is already there.

Obviously, 1 is very stupid, 2 is quite stupid and 3 is usually stupid but sometimes unavoidable due to interface constraints.

4 is better but still quite dumb.

5 and 6 are fine, though my personal preference is for 6 – the message is just chaff and I hate chaff.

*Yes, this was brought on by seeing someone’s dumbass code.

3 thoughts on “Approaches to catching and propagating Exceptions in Java Servlet Programming”

  1. 6 is definitely best… unless the message has something to add to the exception being rethrown, don’t say anything. The stack trace gives all the information you need.

    Another irritant in this area is the perverse semi-use of Hungarian style notation for exception variable name, this particularly happens when there are a string of catches:

    catch(SQLException sqle)
    {
    throw new ServletException(sqle);
    }
    catch(InvocationTargetException ite)
    {
    throw new ServletException(ite);
    }
    catch(BobException be)
    {
    throw new ServletException(be);
    }

    I know this may seem petty and minor, but this is one of those cases, like with simple looping on the variable ‘i’, that a single character ‘e’ would be most appropriate.

    If you have decided that you don’t need a descriptive name (and ‘sqle’, ‘ite’ and ‘be’ above are hardly descriptive) then why not keep it simple and consistent? In fact, the only time you can really justify such undescriptive names is if you use an established standard that we all understand.

    One explanation for this may be that the programmer doesn’t understand scoping and believes that naming all the exceptions ‘e’ will cause a compilation error… who knows, all I know is that like your example 5, it just grates with me.

  2. Well I’m a ‘6’ man myself, but I have to hold up my hands and confess to the ‘semi-use of Hungarian style notation for exception variable name’. My reasoning is simply that that is the style I was taught (incidentally I was also taught never to use just ‘i’ or ‘j’ as loop variable names – a habit which I have since broke). These habits can sort of stay with you I suppose.

    Besides, I’ve seen worse crimes, like this from an anonymous Manchester E-commerce company:


    catch (Exception e)
    {
    System.out.println("there was an error");
    e.printStackTrace();
    }

  3. There are occasions where 3 is the best you can do. For example, propogating an exception in some of the servlet listener interface methods may cause the servlet to terminate, which won’t necessarily be the behaviour you desire.

Leave a Reply

Your email address will not be published. Required fields are marked *