Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder1.news.weretis.net!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: Avoid creating a stacktrace prior to JDK 1.7
Date: Mon, 03 Oct 2011 01:32:40 +0200
Organization: albasani.net
Lines: 32
Message-ID: <j6asas$dgq$1@news.albasani.net>
References: <j64ht6$o64$1@news.albasani.net> <j66puk$h0j$1@dont-email.me> <j66t6a$9ta$1@news.albasani.net> <4424828.699.1317485416810.JavaMail.geo-discussion-forums@prng5> <j67kk4$qf3$1@news.albasani.net> <1058576.2212.1317496868028.JavaMail.geo-discussion-forums@prfh23> <j67rp6$afo$1@news.albasani.net> <j67svg$7om$1@dont-email.me> <j682df$9ve$1@dont-email.me> <16954967.979.1317524784002.JavaMail.geo-discussion-forums@prng5> <j69dh0$qht$1@dont-email.me> <32945439.611.1317569831219.JavaMail.geo-discussion-forums@prni6> <j6aad8$7he$1@news.albasani.net> <j6amcf$r24$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net dko3eB6OzLW88SKDYhxUTYC8E+Yb8a1VfWSGJlPwlWCeSDYI3Ji2z9r2C5D8HurY3aFuOj9QDx/IeDGfCbVFjQ==
NNTP-Posting-Date: Sun, 2 Oct 2011 23:32:44 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="yUFicgieh7hJ215sGxMvnmF/mjxl7Tw/lFHocMMUXk39KhFPqXWyg0l3eN2mA2ndI2YajUgC7GPXbF9VQhy1MQjwEPqBQxuAJW7lWsf6QzgjI2Q3stUqbHE7p81FPTis"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
In-Reply-To: <j6amcf$r24$1@dont-email.me>
Cancel-Lock: sha1:2NNR/iAiDb6FXh/sNXPAQ1ghDQU=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8488

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