StackTraceElement question

[Vitaly Davidovich]

FWIW, .Net's equivalent to this doesn't return the class but exposes the
MethodBase (java.lang.reflect.Method analogous) that owns the frame and one
can get the defining class from that.

Sent from my phone
On Oct 8, 2012 10:35 AM, "Krystal Mok" <rednaxelafx at gmail.com> wrote:

> On Mon, Oct 8, 2012 at 10:25 PM, Christos Zoulas <christos at zoulas.com
> >wrote:
>
> > 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
> >
> > Printing "I" here is expected. After all, that's the class where you're
> getting run()'s implementation from.
> It's not designed to tell people the actual type of the receiver of a
> certain method invocation. And that's what you're really after, right?
>
> - Kris
>
>
>
> > | 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
> >
>