Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8777
| Date | 2011-10-13 22:51 -0400 |
|---|---|
| From | Arne Vajhøj <arne@vajhoej.dk> |
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Where am I? |
| References | <tmac97tlq14j1tk7tfmule337v9sc6q1rh@4ax.com> <j75b1q$4dm$1@dont-email.me> <2Uylq.4186$mH7.2007@newsfe10.iad> |
| Message-ID | <4e97a3bc$0$282$14726298@news.sunsite.dk> (permalink) |
| Organization | SunSITE.dk - Supporting Open source |
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. Arne
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
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