StackTraceElement question

[Krystal Mok]

On Mon, Oct 8, 2012 at 7:27 AM, David Holmes <david.holmes at oracle.com>wrote:

> On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas<christos at zoulas.com>
>>  wrote:
>>
>>  Hi,
>>>
>>> I don't know if this belongs to this list, but if it does not,
>>> please point me to where it does. I think that it would be nice if
>>> StackTraceElement which currently contains:
>>>
>>>      boolean     equals(Object obj)
>>>      String      getClassName()
>>>      String      getFileName()
>>>      int         getLineNumber()
>>>      String      getMethodName()
>>>      int         hashCode()
>>>      boolean     isNativeMethod()
>>>      String      toString()
>>>
>>> It would be more useful for it to also contain:
>>>
>>>      Class<?>     getClass()
>>>
>>> The reason I am asking, is because I have an application where I
>>> would like to find the enclosing class from where the exception is
>>> thrown not the superclass, but I cannot deduce that from the class
>>> name. If STE contained the above method, I could do:
>>>
>>>          Class<?>  c = ste.getClass();
>>>          while (c.getEnclosingClass() != null) {
>>>               c = c.getEnclosingClass();
>>>          }
>>>          return c.getName();
>>>
>>
> Can't you just do Class.forName(getClassName()) and then find the
> enclosing class?
>
> There could be potential class loader issues to
use Class.forName(getClassName()) in this case (most probably caused by
reflective calls).
But then again, giving the user a reference to instead of the name of a
class really gives the user more information then what's been given now
(e.g. class loader info). Which is not necessarily a good thing. I'd second
Alan on having to do more analysis.

- Kris


> David
> -----
>
>
>  to find the class I want, and getClassName() could be just a wrapper:
>>>
>>>          String getClassName() {
>>>              return getClass().getName();
>>>          }
>>>
>>> Is there any reason to store the name instead of the Class<?>? Is it
>>> possible to fix this in a future version of the jdk?
>>>
>>> thanks
>>>
>>> christos
>>>
>>>