Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8781

Re: Where am I?

Show all headers | View raw

On 11-10-14 12:27 AM, Patricia Shanahan wrote:
> 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.

I understand the point you and Arne are making, but I see this issue
differently. Stanimir, and I, have advanced the notion that if the
message is sufficiently descriptive that one can locate the source of it
without difficulty. To answer your criticism, I'd simply say that if one
is so unsure about the quality of their programmers that they can't rely
on the messages being sufficiently descriptive for this purpose, all
that you've really got with the logging infrastructure supplying
location information is _tracing_.

Personally, if I wanted tracing I'd use dtrace if I had it, or use
aspects, or both.

Sure there is a burden on the programmer. Unless one assumes that the
single or main purpose of the log statements _is_ to trace, that burden
is to ensure that the log statements are descriptive and useful. That is
the prime directive. I actually don't see the point in assuming that the
log statements might not be sufficiently descriptive: sure, you can put
in the location specifiers but then you've simply got useless log
statements that you can accurately source.

> 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

But in this case all we are asking the programmers to do is to put in a
sufficiently descriptive log message. That's it. Not requiring them to
at least do that is to defeat the purpose of logging.

I've had the opportunity to gather requirements for, design, and
implement major logging initiatives for a number of large J2EE/JEE
applications. In fact logging improvement, along with error handling
revamp, was the purpose of these mid-life projects. Requirements input
came from both operations support staff (who typically use Splunk to see
logs), and from production support developers (who get tasked with
fixing production defects and who work with the app logs also). I still
do other maintenance and new projects for these clients, so over the
past few years I've gotten useful feedback on how the new logging is
working. It's been quite positive: not only are the logs much better for
their intended purpose, but all the developers like the new system.
_They_ don't think it's a burden.

I'll add that in these work environments that I describe, that logging
is taken seriously enough that log statements (whether existing or new)
are also the subject of code reviews. This isn't 100% coverage, of
course, but there is enough review process that the quality of log
messages stays high.

The only time with these applications, in a production support
situation, that statements could not be unambiguously pinpointed in the
source is because the statements themselves - the meat of the message -
were useless (maybe the work slipped review). Personally I believe that
the answer there is to improve the message.

Again, based on the actual experiment, and observations thereafter, I
simply don't see that assuming that programmers cannot be counted on to
write sufficiently descriptive log messages is a valid concern. Not if
there are at least moderate processes in place. Sure, in a completely
undisciplined shop you may as well put in location specifiers with your
logger of choice, but ultimately all you've got then is tracing.

AHS
-- 
I tend to watch a little TV... Court TV, once in a while. Some of the
cases I get interested in.
-- O. J. Simpson

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Where am I? Roedy Green <see_website@mindprod.com.invalid> - 2011-10-12 17:04 -0700
  Re: Where am I? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-12 17:22 -0700
    Re: Where am I? bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-10-13 09:36 +0100
      Re: Where am I? Arne Vajhøj <arne@vajhoej.dk> - 2011-10-13 17:00 -0400
  Re: Where am I? Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-13 03:23 +0300
    Re: Where am I? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-13 07:16 -0300
      Re: Where am I? Arne Vajhøj <arne@vajhoej.dk> - 2011-10-13 22:51 -0400
        Re: Where am I? Patricia Shanahan <pats@acm.org> - 2011-10-14 04:27 +0100
          Re: Where am I? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-14 07:26 -0300
            Re: Where am I? Arne Vajhøj <arne@vajhoej.dk> - 2011-10-14 18:17 -0400
    Re: Where am I? Roedy Green <see_website@mindprod.com.invalid> - 2011-10-13 10:51 -0700
  Re: Where am I? Ian Shef <invalid@avoiding.spam> - 2011-10-13 00:39 +0000
  Re: Where am I? markspace <-@.> - 2011-10-12 18:00 -0700

csiph-web