记录和包装异常。 这是好习惯吗？

Question

Do you think it's worth it to wrap all service methods in a try catch block to log exceptions like this:

public void attachClean(Car instance) {
    log.info("attaching clean Car instance");
    try {
        getSessionFactory().getCurrentSession().lock(instance, LockMode.NONE);
        log.info("attach successful");
    } catch (RuntimeException re) {
        log.error("attach failed", re);
        throw re;
    }
}

it seems like a lot of typing

Answer 1

You usually log OR rethrow, but not both. Upper layers may be able to handle the exceptional state, and logging entire stacktrace would be unnecessary in such case. Hovewer, if you absolutely want to make sure it's logged, you can log it on your own. Logging exception multiple times is better than missing important exception in the log file.

Answer 2

This is a terrible practice. You have achieved nothing except more typing, probably duplicated stack trace in logs and few additional lines to test. If this is a RuntimeException and you can't handle it anyhow (logging != handling), just let it fly higher, maybe someone will be able to handle it properly (framework/container preferably).\\

BTW it is a could practice to always log some sort of context on which you work, so you might want to write something like (SLF4J dialect):

log.info("attaching clean Car: {}", instance);
getSessionFactory().getCurrentSession().lock(instance, LockMode.NONE);
log.info("{} attach successful", instance);

Answer 3

Think about how the logs will look if everything does this. Then think about how it will look if no one does.

You need a reasonable balance. For instance, if you're creating an API you may want to log things that leave your library into user code.

Answer 4

You can let a dependency injection framework like Spring do the heavy lifting, by configuring it to decorate your classes with AOP proxies . The linked example shows how to use it for authorization checks, but logging would be very similar.

Answer 5

In my opinion... NO.

It is another thing if you are catching the exception and handle the request accordingly, for example, performing somesort of cleanups. However, if you merely doing a try and catch just to log the error, then it doesn't make sense. After all, the stacktrace from the runtime exception will tell you where the exception occurs. You can do a "catch-all" at the very top instead of doing try-catch all over the places.

If you really paranoid, you can use AspectJ's "around" advice to perform a centralized "try-catch-log-error" block. That is much better than polluting your code with those ugly try catch blocks that do almost nothing.

Answer 6

If your method attachClean is a part of external interface of your system, then logging is cruicial.. Otherwise, you dont have any clue about the exceptions your clients receive..

If this method is part of internal implementation of your system, logging is unnecessary. Because the exception would be handled by your external interface.

Answer 7

I wouldn't rethrow the exception. You'll have to catch it again, adding more boilerplate code.Also, code inside a try is slower.