Avoid creating a stacktrace prior to JDK 1.7

[Jan Burse]

There's a difference between "no information" and "information that
there is no information". The latter tells you something, at least.

My original question was: How can I force an exception to not
record some stack frame list at all.

One proposed solution so far was pre-allocating exceptions
from a call site with a few stack frames. Eventually also
calling the following method on the pre-allocated exception:

setStackTrace(new StackTraceElement[0]);

So as to even free the stack trace that was allocate from the
call site with only a few stack frames. The above method is
available since JDK 1.4.

What about calling setStackTrace() just after the new and before
the throw. This would only give a space advantage but not a
time advantage.

Any other suggestions?

Bye

 

[Eric Sosman]

There's a difference between "no information" and "information that
there is no information". The latter tells you something, at least.

My original question was: How can I force an exception to not
record some stack frame list at all.

One proposed solution so far was pre-allocating exceptions
from a call site with a few stack frames. Eventually also
calling the following method on the pre-allocated exception:

setStackTrace(new StackTraceElement[0]);

So as to even free the stack trace that was allocate from the
call site with only a few stack frames. The above method is
available since JDK 1.4.

What about calling setStackTrace() just after the new and before
the throw. This would only give a space advantage but not a
time advantage.

I've become confused about what you're looking for. The thread
began with your desire to avoid filling a stack trace entirely:

Will it every time I call it for a
non-existing class build the whole stack
trace for the exception x and then
immediately forget about it? [...]
If I were to write my own forName()
method I would set the writableStackTrace
to false if the exception is only needed
to immediately notify the callee about
something.

From this perspective, how does it improve matters if you replace
a filled-in trace with a new one of your own devising, however short?
What is your goal?

 

[Jan Burse]

From this perspective, how does it improve matters if you replace
a filled-in trace with a new one of your own devising, however short?
What is your goal?

In the pre-allocated case less memory usage. In the dynamic
case, earlier GC of the stack trace. This is known as
"agressive" pointer zeroing.

An effect to GC would only be seen if the exception it self
is not immediately reclaimed. For example when the try-catch
rippling process is slow or when it is somewhere retained on
the top level.

For example I have seen the following programming pattern:

try {
validateFormFields();
} catch (ValidationError x) {
informEndUser(x);
}

You usually don't show a stack trace to the en-user. You
generate some user friendly message. But the above example
does not fully work as an example, since the high frequency
use of the exception is missing.

But any, the bets are open. Any further suggestions to
have exceptions without the stack trace created in the
first place?

Bye