On Mon, Oct 8, 2012 at 7:27 AM, David Holmes <[email protected]>wrote:
> On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas<[email protected]> >> 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. - Kris > 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 >>> >>>
