> I've found that there's always something useful you can (and should) > say in such cases. Even if it's just: "Failed to do X", where "X" is > the stuff inside the try block. Giving even minimal context to the > exception is *really* useful in many cases, especially since many > logging configurations out there don't include stack traces or line > numbers in the log output... > > So IMHO having the logging API force you to say at least something > beyond the exception you got is a Really Good Thing (TM).
I disagree that this is always the case - couple of use cases: 1) Logging in the uncaught exception handler for a thread. All I've got is the exception - I know nothing about what caused it. Particularly if I'm setting the default exception handler for an application that takes plugins of some sort. 2) Logging an exception from a service in a controller. The controller is very light - passes some args to the service and puts the result into the model. The service catches all exceptions and throws them in a higher level service specific exception with all the contextual info (args etc.) in the higher level exception's message. The fact that the service was called by this particular controller is in the stack trace. There is nothing further I can add that doesn't just repeat info I already have in the exception's message and stack trace. If I need to put some extra info into a logging message it would make me think about whether I could get that info into the exception in the first place; could I create it with a better message? Have I failed to include the cause? Could I catch a low level exception and throw a higher level exception with a message and the cause? _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
