StackTraceElement question (original) (raw)

Christos Zoulas christos at zoulas.com
Mon Oct 8 14:25:18 UTC 2012

On Oct 8, 11:07pm, david.holmes at oracle.com (David Holmes) wrote: -- Subject: Re: StackTraceElement question

| > There is also the problem of having a class hierarchy like: | > | > class A extends class I | > class B extends class I | > | > and then trying to figure out if it is A or B when you just have I from | > that StackTraceElement. || Can't say I have ever studied stacktraces in depth but I would expect to | see A or B not I as the name.

I was expecting the same, but this is not the case:

$ cat StackTrace.java class I { public void run() throws Exception { throw new Exception(); } }

class A extends I { }

public class StackTrace { public static void main(String[] args) { try { A a = new A(); a.run(); } catch (Exception e) { StackTraceElement[] ste = e.getStackTrace(); for (int i = 0; i < ste.length; i++) System.out.println(ste[i].getClassName()); } } } $ javac Stacktrace.java $ java -cp . StackTrace I StackTrace

| The loader issue is real, you'd have to know where to locate the class. | But another reason to not store the Class reference is that it may | prevent the class from being unloaded. For every use-case there's a | counter-use-case.

Yes, the class loader issue is real. I am not sure about the Class reference preventing the class to be unloaded; after all, the StackTraceElements are typically transient (when the exception goes out of context, they can be GC'ed); if not, then the reference can be held until the StackTraceElement is not reachable. I don't think that keeping the reference is such a big issue to even consider making this Weak. I am really worried about the security implications. As far as serialization goes, it could be made transient for compatibility. Anyway, I would be more than happy the StackTraceElement contained the outermost enclosing class instead of the immediately enclosing one. Returning the Class<?> instance is still the most versatile, but the one that needs most consideration because of its implications.

christos

christos

More information about the core-libs-dev mailing list