CODEWITHSUNDEEP
loggingjava.util.logging
Daniel C
Daniel C

Reputation: 2500

The parameters in the entering/exiting methods of the Java logger

Assuming the use of java.util.logging.*, what would be appropriate arguments to use in myLogger.entering(...) and myLogger.exiting(...)? If these are always supposed to be the source class name and source method name, why doesn't the method finds the information itself instead of asking us for it? The methods documentation says:

This is a convenience method that can be used to log entry to a method. A LogRecord with message "ENTRY", log level FINER, and the given sourceMethod and sourceClass is logged.

This is a convenience method that can be used to log returning from a method. A LogRecord with message "RETURN", log level FINER, and the given sourceMethod and sourceClass is logged.

Should we simply hardcode the method name, i.e. using " "? My possibly incorrect rationale is that if what my getMethodName() does is acceptable for heavy usage then the logging system would be doing it itself instead of asking us for the method name.

private static void methodNine() {
    logger.entering(LogTest.class.getName(), getMethodName());

    logger.exiting(LogTest.class.getName(), "sourceMethod");  // sourceMethod=?
}

/** @return The current method name. */
private static String getMethod() {
    return Thread.currentThread().getStackTrace()[2].getMethodName();
    //[0]=getStackTrace, [1]=getMethod, [2]=<method name we're looking for>
}

Upvotes: 1

Views: 1159

Answers (1)

jmehrens
jmehrens

Reputation: 11045

Assuming the use of java.util.logging.*, what would be appropriate arguments to use in myLogger.entering(...) and myLogger.exiting(...)?

According to the documentation, it is the source class name and the source method name. However, it is sometimes nice to bend the rules in cases of anonymous classes to include the declaring class and enclosing method name along with the anonymous method and class name separated by a special identifier. The trade off is that the filtering of some LogRecords might get tricky if the filter is expecting some standard class/method format.

If these are always supposed to be the source class name and source method name, why doesn't the method finds the information itself instead of asking us for it?

When the logging API was created computing the callsite at runtime was expensive compared to just supplying a constant. There still is a cost today.

For dynamic proxies it is nice to use the given method name instead of the handler class and method. Also, the Java Native Interface might have trouble computing the current method in native code.

Should we simply hardcode the method name, i.e. using " "? My possibly incorrect rationale is that if what my getMethodName() does is acceptable for heavy usage then the logging system would be doing it itself instead of asking us for the method name.

Depends on your requirements. If you think 'getMethodName()' is fast enough today and X years later for what you are doing then you have to determine if there will be any coding debt with this pattern. There is a draft JEP to create an Efficient Stack Walking API so you might be able to up the performance in the future.

You could just create a local variable called 'methodName' as the first line of every method and do about the same thing.

Upvotes: 1

Related Questions