Logging can become quite verbose. I found myself writing a method in which most of the lines were logging related, which really clutters the code:
if (source == null)
{
if (log.isDebugEnabled())
{
log.debug("No copy required as no source provided (dest \
was "+dest.getAbsolutePath()+")");
}
return;
}
Possibly I'm over-logging, to try to avoid ever running a debugger. But I was wondering if it'd be possible to do something so that I could turn on logging of comments for a given method, class, package or whatever. So if I'd written....
if (source == null)
{
// No need to copy as no source directory provided when copying to dest
return;
}
...and there was some way to say "show me the comments as you execute", that would be as useful as my four lines of debugging. You could even imagine this hypothetical tool could spot references in comments to variables in scope and do a
This wouldn't replace logging (you'd still want error, info, fatal, etc), but it might be a useful piece of ease-of-use. From what I can tell Java doesn't preserve comments in the bytecode, so it's not something easy to do. But we have annotations and reflection and AOP and static analysis and assertions and all sorts of stuff, so there's probably some way to make it happen.
if (source == null)
{
if (log.isDebugEnabled())
{
log.debug("No copy required as no source provided (dest \
was "+dest.getAbsolutePath()+")");
}
return;
}
Possibly I'm over-logging, to try to avoid ever running a debugger. But I was wondering if it'd be possible to do something so that I could turn on logging of comments for a given method, class, package or whatever. So if I'd written....
if (source == null)
{
// No need to copy as no source directory provided when copying to dest
return;
}
...and there was some way to say "show me the comments as you execute", that would be as useful as my four lines of debugging. You could even imagine this hypothetical tool could spot references in comments to variables in scope and do a
toString on them.This wouldn't replace logging (you'd still want error, info, fatal, etc), but it might be a useful piece of ease-of-use. From what I can tell Java doesn't preserve comments in the bytecode, so it's not something easy to do. But we have annotations and reflection and AOP and static analysis and assertions and all sorts of stuff, so there's probably some way to make it happen.


5 Comments:
The trouble with annotations is that they only apply at method/class/field declarations. Not at the statement level.
Also, I always wonder why people say if (log.isDebugEnabled()) {}. Surely it doesn't make that much difference to the runtime. It always seemed like clutter...
Thanks for the comments Dom.
Regarding the isDebugEnabled check, you're quite right in that it really doesn't make that much difference for some cases. If you're logging a String or (more generally) an Object, I wouldn't bother with the check. I did test this: for a million logging calls, the if check saved me 5-10 milliseconds in total; but I guess it depends on your point of view and what you're doing to decide if that's worth it or not compared with the hassle of adding the if.
As far as I can tell, when doing anything more complicated in the debug (e.g., string concatenation) you're honour-bound to add the if. In my one million logs test, the if cost me 20 milliseconds compared to 700 without the if.
I wonder if this could be possible through the JDI, the debugger can find the location in the source, so why not be able to output comments between each executed line of source?
Although I do wonder if this did happen whether we'd end up with more comments like:
// set x to y
// entered method
as a short cut for debug messages which might make it more difficult to sport the real comments.
Personally I thinks it's about taking more care what you debug, and sometimes you just have to use that debugger :)
Thanks Richard (you can never have too many Richards).
If it is the case (as it looks) that the source is going to be required to do this, then that's going to cause a problem for some people. You might, for example, need to ship the right version of the source to get in-the-field debugging.
Maybe this is too involved to be worth it. Like you say, a careful use of debugging might be what this is about.
Keep an eye on Logback: http://logback.qos.ch/
It's a logging framework from the creator of log4j: "It builds upon experience gained in building industrial-strength logging systems going back as far as 1999". I'm expecting great things from it.
Regarding the whole IsDebugEnabled thing, Logback offers parameterized logging (i.e., sprintf-style) to reduce the need for the check. See here: http://www.javadonkey.com/blog/log4j-isdebugenabled-logback/
Post a Comment
<< Home