On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
> if (isDebugLoggingEnabled()) {
> log.debug("And the answer is: " + expensiveMethodCallHere());
> }
>
> I don't know about you, but I'm very thankful for that guard when
> debug
> logging is disabled (e.g. in production). Without it, I'm going to
> make that
> expensive method call even if logging is disabled - and then just
> throw away
> the result after doing nothing in log.debug. Even a lowly toString
> () call,
> frequently used in debug logging, can get expensive, so it's not
> like this
> is a corner case.
>
> -1 on getting rid of guards.
I agree that in rare cases you might want to be able to do this
still. But in the vastly more common 2nd case you cite (the
expensive toString() call), that's entirely the point of this. Log
methods take Object.../Object[] and only toString the objects in the
array if the appropriate log level is enabled.
No, I don't think you're getting what I'm saying. I'm not talking about
internal toString() calls, I'm talking about something like:
log.debug("And the answer is: " + myBigObject.toString());
That toString() method is going to be invoked before the log.debug method is
ever called, so the cost is sunk even if debug logging is disabled.
Now, I get the point that I should probably have used a parameterised string
and passed in myBigObject, letting the log method to the toString() call,
but people are so used to doing things like the above that it will still
happen.
--
Martin Cooper
-t
