Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know exception handling is a topic often discussed in the world of Java. I've read a few threads on here and SO as well.

http://stackoverflow.com/questions/2169339/exception-handling-in-a-java-web-application

I find myself identifying with principles such as Do not suppress or ignore exceptions, Do not catch top-level exceptions, and avoid anti-patterns like Log and Throw.

http://today.java.net/article/2006/04/04/exception-handling-antipatterns#throwingException http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html?page=2

Question #1, is there a different standard of practice when it comes to web applications? For example, is it a legitimate use case to catch Exception for logging purposes and then throw it up the stack?

function void xyz() throws Exception {
    try {
    } catch (Exception e) {
        LOG.error("ERROR: " + e);
        throw e;
    }
}

function void otherFuncA() throws Exception {
    xyz();
}

function void otherFuncB() {
    try {
        xyz();
    } catch (Exception e) {
        LOG.error("ERROR: " + e);
        throw e;
    }
}

I am finding it very hard to accept as a practice because it is generating so much unnecessary code (see otherFuncA and otherFuncB), affecting the function calls all through the different layers (DAO, Service, Controller, etc.)

Question #2, do I lose information about an error (let's say what caused a NullPointerException) if I let unexpected, unchecked exceptions float up to the Controller layer and then, and ONLY then, handle it there (catch Exception and throw stack trace)? As opposed to logging immediately, and re-throwing (seen above).
Of course, I will still check for specific exception types where applicable.

I seem to find the stack trace is often a better indicator of what went wrong vs. which specific field was causing an error... I am really interested in input from more experienced developers and what best practices/reasoning guide your exception handling.

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

1) No.

2) Not if you put relevant information into the Exception's message - I find that a much preferable alternative.

share|improve this answer
    
Can you elaborate a little on point #2? Do you mean to put relevant info at each layer and re-throw up the stack? Or how do you mean put in relevant info at the controller layer? –  user1766760 Mar 25 '13 at 16:01
    
@user1766760: I mean add the information where you have it, and that's very rarely at multiple levels - usually you can do it at the lowest level when the exception is created. –  Michael Borgwardt Mar 25 '13 at 16:15
    
so if say, the exception happened in the DAO layer (and I capture the values used for a query), then... should I assume this means to 1) create a new custom exception (with the extra bits of info) 2) fail fast (so throw exception, but doesn't this mean I have to throw/catch it all the way up the stack?) –  user1766760 Mar 25 '13 at 16:30
    
@user1766760: 1) only create a custom exception if you expect its specific type to be caught, otherwise just put the information into the message. 2) not sure what you mean - the point of using exceptions is that the calling code can decide at what level to handle it. –  Michael Borgwardt Mar 25 '13 at 16:35
    
I think I am confusing myself about turning an unchecked exception to a checked exception. I assumed when the extra bits of info are added, I had to declare throws XYZException (which is not the case, right?) –  user1766760 Mar 25 '13 at 16:53
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.