Am 26.12.2013 23:28, schrieb Chris Pratt:
I'm not sure what you are saying is "happening so rarely" for you?? Are
you saying you log information so infrequently that you rarely either do
log.debug("The file " + file.getAbsoluteFile().toString() + " was created
on " + file.lastModified())
Nah, I'm using logback for a reason.
> or do log.debug("The file {} was created on
{}",file.getAbsoluteFile().toString(),file.lastModified());?
This.
> In both
cases, you are performing computations that are thrown away in a production
environment.
Sure. So what?
90% of the code isn't running very often anyway.
Of the 10% that are run in a tight loop and are potentially(!)
optimization-worthy, 99% are just parameterless getters (it's
exceedingly rare that something that's log-worthy isn't already
available as a member field somewhere).
My observation has been that the remaining 0.1% are easily wrapped in an
if() statement.
BTW Java wraps the variable parameter list in an array, which is an
overhead that should dwarf that of inlineable simple getters. What takes
the time is the string concatenation, not the member field accessors.
Ceki had a valid point that replaceable loggers would be a bad idea, so I'm
no longer proposing that. My proposal would be for a single, more
powerful, formatter that could handle something like log.debug("The file
{0.absoluteFile} was created on {0.lastModified,date,yyyy-MM-dd",file);
So you're not just after getters but after a full expression language.
Which I think is a bit over the top for something that (a) rarely
matters, (b) is already deep in the area of diminishing returns, (c) has
a workaround, (d) will become irrelevant with closures, and (e) causes
lots of untested executable strings until they are actually executed.
Sure, you seem to have a readymade solution so the problems wouldn't
affect anybody except those using your lib.
But it's the opposite of KISS. And logging should follow that principle,
simply because if logging fails you're in deep trouble because you lose
your diagnostics.
I'm using a fairly complicated logback appender, which did run into
failure and which I'm pretty unhappy about. But at least I can specify
alternate, more primitive and hence more robust appenders. The formatter
is on a code path that constitutes a single point of failure; have a bug
in the format string and the message will never be emitted.
You could work around that by catching exceptions and emitting the raw
format string and appending the parameter values, but (1) the parameter
values won't help much because you're after details from their innards,
and (2) the exception should be logged but you can't log from inside
logging code, SLF4J will drop such log messages to prevent endless
recursion.
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
