log & throw antipattern

[rinke hoekstra]

Hi all,

I found this article, and realized I'm using his number one Exception antipattern quite often: log and throw.

I was wondering:
are people using this too? What is so bad about it? And if it is so bad, why is there a Logger.throwing method? If it was so bad, it wouldn't make sense to have Logger.throwing, would it?

[John Stone]

Yes, I'm using it too.

http://homepage.mac.com/jimothy/articles/exceptions/horrorStories.html

I guess, I'll re-consider my approach.

[Musab Al-Rawi]

say ClassA.fooI() calls ClassB.fooII() where this is an exception that occurs, if you log the exception and RE-throw it and inside fooI() you catch it again and log it then the exception is loged twice.

as a debugger you will see multiple messages for the same exception which makes it deffecult to read logs and figure out which messages are shadows of other messages and which are not. the article makes alot of sence.. but of course you could argue that keeping a different log for each class should at least split/seperate the messages, but what if fooI() and fooII() are in the same class.
[ August 28, 2007: Message edited by: Musab Al-Rawi ]

[Herman Schelti]

hi Rinke,

I use logging and throwing too, like this

catch (NoSuchMethodException e) {
LOG.error("I really like something readable in my logfiles", e);
throw e;
}

I find it helpfull to have something readable in my logfiles, and not just stacktraces.
And I don't think "this makes life hell for the support engineer".


Herman
[ August 28, 2007: Message edited by: Herman Scheltinga ]

[Musab Al-Rawi]

Herman,

correct but i think the article talks about double logging, when you catch the thrown exception in the calling method.

[rinke hoekstra]

Originally posted by Musab Al-Rawi:
Herman,

correct but i think the article talks about double logging, when you catch the thrown exception in the calling method.

Yes, good point. It is clear that it is best to log an exception only once, and not with throwing AND with catching. Apparently the article states that logging at catching is better than logging at throwing. I'm not sure why that should be.

However, I can still think of a situation where double logging (at throwing and at catching) is good: if the exception is thrown at the server, passed via rmi to the client, and caught at the client. In that case double logging does make sense, as both logged messages will appear in different log files at different machines.

[Gabriel Vargas]

Hi Rinke,

After read your post i test my application in networked mode in two machines and i see than exceptions are only logged in log of the client because my controller is the only than can log application exceptions, before i only test my application in only one machine in networked mode and i can't see that thing (also i separate the logs depending application mode), so in my services layer (server side) i log the exception with "Server :" prefix and throw again the exception to keep log in server, but in stadalone there are a double logging as tradeof to keep server exception logging. I think is better do this because logger of the client isn't always avaible for a lot of reasons so see log in the server can help if an issue happens.

I hope it helps.

[rinke hoekstra]

Hi Gabriel,

yes, good idea to use these prefixes in the logging message.

[Jason Moors]

Very interesting article, I tend to putting logging everywhere and then configure the logging levels for each Logger depending on whatever I'm trying to debug. i.e. if I'm trying to debug the db package I just set the suncertify.db.level in my jre/lib/logging.properties file.

Jason

# Loggers
# ------------------------------------------
# Loggers are usually attached to packages.
# Here, the level for each package is specified.
# The global level is used by default, so levels
# specified here simply act as an override.
suncertify.gui.level=SEVERE
suncertify.server.level=SEVERE
suncertify.db.level=ALL