[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Query on stacktrace management logic
From: |
David Holmes |
Subject: |
Query on stacktrace management logic |
Date: |
Fri, 27 Feb 2004 15:49:32 +1000 |
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
- Query on stacktrace management logic,
David Holmes <=