«

Lew schrieb:
> 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

On 10/2/2011 2:26 PM, Jan Burse wrote:
>
> Lew schrieb:
>> 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?

--
Eric Sosman
d

Eric Sosman schrieb:
> 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