StackTraceElement are Serializable and because they don't store any class,
you can send an exception from the server back to the client without
requiring
that the client knows the classes loaded by the server.
So at least, if the class is provided, this should be done optionally
because
the class should not be serialized.
cheers,
Rémi
On 10/08/2012 03:07 PM, David Holmes wrote:
On 8/10/2012 9:48 PM, [email protected] wrote:
On Oct 8, 7:33pm, [email protected] (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.
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
