Hello all, I'm somewhat baffled why Throwable's stacktrace management is implemented like this:
private transient VMThrowable vmState; private StackTraceElement[] stackTrace; public Throwable fillInStackTrace() { vmState = VMThrowable.fillInStackTrace(this); stackTrace = null; // Should be regenerated when used. return this; } public StackTraceElement[] getStackTrace() { if (stackTrace == null) if (vmState == null) stackTrace = new StackTraceElement[0]; else { stackTrace = vmState.getStackTrace(this); vmState = null; // No longer needed } return stackTrace; } Rather than the much simpler: private StackTraceElement[] stackTrace; public Throwable fillInStackTrace() { stackTrace = VMThrowable.fillInStackTrace(this).getStackTrace(this); return this; } public StackTraceElement[] getStackTrace() { return stackTrace; } Give that VMThrowable guarantees to return a non-null array if there is no stack trace, and given that fillinStackTrace is called at construction, this would seem adequate. What did I miss? The reason this came up is that I'm looking for a way to construct throwables (specifically certain instances of OutOfMemoryError) without having the stacktrace filled in. I can obviously hack Throwable but I'd prefer to deal with this only through VMThrowable if possible - but it's not looking possible. I need to add a private constructor to Throwable that doesn't do fillInstackTrace by default, which I can then call from the VM. Any insights appreciated. :) Cheers, David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath