StackTraceElement question

[David Holmes]

On 8/10/2012 11:07 PM, David Holmes wrote:
> On 8/10/2012 9:48 PM, christos at zoulas.com wrote:
>> On Oct 8, 7:33pm, rednaxelafx at gmail.com (Krystal Mok) wrote:
>> -- Subject: Re: StackTraceElement question
>>
>> |> 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.
>>
>> 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.

No I take that back. The class would be that defining the method, not 
the class of the object the method is invoked upon.

But then it doesn't matter if you store the class or the class name, you 
are going to get I not A or B.

David
-----

> 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.
>
> David
>
>> Alan is right, there could be security issues providing the class, and
>> it is annoying and expensive to have to deal with them in the code
>> that fills in StackTraceElement, and there could be also serialization
>> issues. I think it is still a useful change though...
>>
>> christos