classpath
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]