I agree completely too. If exception handling/logging is being done in the
correct places I'm yet to see a situation where there isn't some useful contextual
information that can and should be added to the message. If there isn't anything
to add, you invariably shouldn't be handling the exception at that level.
I've failed plenty of code reviews for this reason over the years, and I'd
automatically fail any code that was just calling logger.error(ex). I'm quite
fussy about this these days; there have been far too many occasions in the
past where I've had a production app failing without logging enough information
to diagnose the problem, even though it was clear that the information was
in fact available at runtime. Having to fix the logging then wait until production
falls over again before the problem can be isolated is a horrible situation
to find yourself in.
Note that I also feel that assuming your logging configuration will write
out thread names etc is a bad idea; that is external configuration that can
change outside of the control of your code and it's better to be explicit
about it, in the places where it obviously matters.
Just my 2c.
Chris
I agree 100%. Having only the methods as they are now kind of enforces
a better overall logging style.
While one still has the option to simply call logger.error("",ex) it
should seriously make you feel a bit guilty, especially in
non-trivial, larger projects... I'd also point at it in a code-review,
asking "wtf?" ;)
Regards,
Joern.
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
