logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: Clever Logging?
Date Mon, 14 Jan 2002 21:43:42 GMT

This is what the JDK 1.4 javadocs say.

Class java.lang.Throwable
=========================

getStackTrace
public StackTraceElement[] getStackTrace()

  Provides programmatic access to the stack trace information printed by
  printStackTrace(). Returns an array of stack trace elements, each
  representing one stack frame. The zeroth element of the array
  (assuming the array's length is non-zero) represents the top of the
  stack, which is the last method invocation in the sequence. Typically,
  this is the point at which this throwable was created and thrown. The
  last element of the array (assuming the array's length is non-zero)
  represents the bottom of the stack, which is the first method
  invocation in the sequence.

  Some virtual machines may, under some circumstances, omit one or
  more stack frames from the stack trace. In the extreme case, a virtual
  machine that has no stack trace information concerning this throwable
  is permitted to return a zero-length array from this method. Generally
  speaking, the array returned by this method will contain one element
  for every frame that would be printed by printStackTrace.

Uncertainty seems to remain...


At 13:38 14.01.2002 -0800, you wrote:
>Getting information from the stack trace will be much easier in JDK 1.4
>with the new Throwable class. The stack trace is represented as an array
>which you can get reliable data out of.
>
>Too bad JDK 1.4 is lagging WAY BEHIND! Any idea when it will be
>released?
>
>Chris
>
>-----Original Message-----
>From: Ceki Gülcü [mailto:ceki@qos.ch]
>Sent: Monday, January 14, 2002 1:35 PM
>To: Log4J Users List
>Subject: Re: Clever Logging?
>
>
>At 15:39 14.01.2002 -0500, you wrote:
>>That all worked fine, except that developers would make the mistake of
>>putting the wrong class name inside the getInstance() method.  This
>would
>>usually happen when they would cut and paste code.  
>
>The idea of automatically discovering the caller class name has been
>suggested before, I believe by Anders Kristensen along similar lines.
>It would be nice to have a reliable method to retrieve the caller
>class name. However, I am not aware of any such method.
>
>>So, one of our developers came up with a clever solution to cut down on
>the
>>mistakes.  He created a logging utility that could automatically read
>the
>>stack frames, discover which class logged the message, and invoke
>logging
>>from the proper Category.
>>
>>Here is how he did it:
>>
>>public class LogUtil {    
>>    /**
>>     * Extends <code>java.lang.SecurityManager</code> to provide the
>><code>getClassName()</code>
>>     * method.
>>     */
>>    private static class ClassGetter extends SecurityManager {
>>        // Inner class necessary because getClassContext() is protected
>>        
>>        /**
>>         * Returns the name of the calling class.
>>         * @return  the name of the calling class
>>         */
>>        public String getClassName() {
>>            // getClassContext() returns the current execution stack
>trace
>>            // as an array of classes -- the element at index 0 is the
>class
>>            // of the currently executing method, the element at index
>1 is
>>            // the class of that method's caller, and so on. So, 0 is
>going
>>            // to be this class (ClassGetter), 1 will be LogUtil, and 2
>will
>>            // be the magic number we are after.
>>            return getClassContext()[2].getName();
>>        }
>>    }
>
>This is pretty smart. However, is it guaranteed to work? How long do
>you think it will take you to debug a problem with
>getClassContext()[2].getName() compared to a typo? The goal was to
>avoid errors, remember? Can it be that you are trading one evil with
>even a worse one? 
>
>If getClassContext()[2].getName() is guaranteed to work, then it is a
>useful feature, otherwise it is evil. I would not take any chances...
>
>
>>    public static boolean DEBUG() {
>>        Category cat =
>Category.getInstance(classGetter.getClassName());
>>        return cat.isDebugEnabled();
>>    }            
>
>The DEBUG method calls Category.getInstance method which is
>not particularly fast. As such, this DEBUG method will incur
>a constant penalty. I suspect this is not what you want.
>
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>
>--
>To unsubscribe, e-mail:
><mailto:log4j-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail:
><mailto:log4j-user-help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>


Mime
View raw message