StackTraceElement question (original) (raw)

Krystal Mok rednaxelafx at gmail.com
Mon Oct 8 11:33:38 UTC 2012

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.

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

More information about the core-libs-dev mailing list