Re: Exception Handling

Lew wrote:
[ SNIP ]
We may be talking/thinking at cross-purposes here: you, me, the article
author, and Novice. The logging article author states that you should
never include file name, class name, or line number. To be accurate the
article is an edited compilation of what another fellow (Tomasz
Nurkiewicz) has written about logging: I haven't been able to find the
originals to see what Tomasz put forth as explanation for this stance.

Further, and presumably this also comes from Tomasz, it's stated that
"logging class name, method name and/or line number has a serious
performance impact." Now, to be fair to him this is also still
promulgated by Ceki Gulcu's log4j documentation.

I suspect that in recent years with newer JVMs that the performance
impact of some of the position conversion specifiers is considerably
less than it was when the warnings were first issued.

Having said that, *my* argument against regularly using source position
information is motivated by retaining clarity of logs. Try reading logs
in a text editor or on the console when the first part of every entry is
not only level and timestamp and thread ID but also FQ classname,
methodname, and line number. That positional info is irrelevant almost
all the time, and yet a _default_ decision to include it seriously
clutters logs. The info you really want starts halfway across the editor
window. The human eye is also not that great at differentiating one blob
of letters from another; ignoring the level and timestamp is easy (they
"look" different when scanning), but the positional info easily runs
together with the real message.

My position is, if you need it, include it. Don't default (let's say
through PatternLayout strings) to having it uniformly. Bear in mind (if
performance is still any kind of concern) that the log4j %c conversion
specifier gives you classname for free if you're creating loggers by
class. You don't need it for errors, not if you're dumping stacktraces.
You surely don't need it for info or warnings. Debug may or may not
benefit from positional information, but that should be case by case,
and if you do need a debug statement to include positional info, what's
so tough about putting it in that one, specific debug message?

[ SNIP ]

Not often in the real world can you do that, Lew. And you know it. One

source of work like this (fixing errors) for ops support and maintenance
programmers is operational problem reports (trouble tickets etc)
detected and entered by business. Another is ops support monitoring
(Splunk, say) of logs...in which case something they detect may also
enter the ticket/defect tracking systems.

Unless something is truly critical nobody is going to shut down a 24/7
public-facing or partner-supporting (b2b) system just because a
programming error popped up as a runtime exception. In fact, in the
absence of any problem reports from the field an issue like that might
well end up as a low/medium severity, low/medium priority defect - mixed
in with dozens or hundreds of others - that'll get handled a few weeks
or months later.