Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Jan Burse Newsgroups: comp.lang.java.programmer Subject: Re: Avoid creating a stacktrace prior to JDK 1.7 Date: Sat, 01 Oct 2011 23:14:10 +0200 Organization: albasani.net Lines: 35 Message-ID: References: <4424828.699.1317485416810.JavaMail.geo-discussion-forums@prng5> <1058576.2212.1317496868028.JavaMail.geo-discussion-forums@prfh23> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net bL1AViW6QTYeGbgQlZfJXp3P5w9wEwzRd8Be6bTNqY1oxiGw8BrXcZYWF4zp+tPZx2AfIL2LWwN9BALF+sH7mA== NNTP-Posting-Date: Sat, 1 Oct 2011 21:14:14 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="v+N3USxh1OJmHQBarFFy7WQ+RotT7GVW57+k6Etyy2tjJtIY7vi77eaWJvQ3NAF6GlpcWE0HOvUCW/PxI+yRiuq4iVWGexUaaQQ9kwOlldrTPiRQbB3fQPqfIJWswkDJ"; 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: Cancel-Lock: sha1:5V97pKb8cJRCn6/Ub+LIToipipM= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8466 Eric Sosman schrieb: > ... and there you have it: Exceptions without (most of) the expense > of filling a stack trace. Also, it must be noted, Exceptions with > less ability to help in debugging than almost any others. Actually this is a good solution. To pre-allocate exceptions with a small stack trace! Thank you for the good idea. The solution could be even spun further. Why not create a separate thread, that will provide a service that will create exceptions without a big stack trace. Will need a little synchronize, but could also work. > Personally, I think "Don't Do That" is sage advice here. Well it exists in JDK 1.7 for some reason. But you cannot do it off hand, you can only do it for your own exceptions since the constructor is protected. I guess a typical usage scenario would be the creation of a stack overflow exception or a memory exception, so as to allow the application to recover. Usually a stack overflow exception is not so interesting, most often it is caused by a loop that starts somewhere and all you have is the same method displayed over an over. > ("Almost" because I've heard somewhere that the JVM > creates a few Throwables like VirtualMachineError in > advance, because by the time they're needed the JVM > can no longer trust itself to fill them in properly.) gr8, one more business case! Bye