Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Avoid creating a stacktrace prior to JDK 1.7 Date: Sat, 1 Oct 2011 12:21:07 -0700 (PDT) Organization: http://groups.google.com Lines: 61 Message-ID: <1058576.2212.1317496868028.JavaMail.geo-discussion-forums@prfh23> References: <4424828.699.1317485416810.JavaMail.geo-discussion-forums@prng5> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 216.239.45.130 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1317496868 5646 127.0.0.1 (1 Oct 2011 19:21:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 1 Oct 2011 19:21:08 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.239.45.130; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8457 Jan Burse wrote: > Lew schrieb: >> in the first place. >> >> /Effective Java/, Joshua Bloch, "Item 57: Use exceptions only for except= ional conditions". >=20 > The JDK itself violates this rule. For example > each time a Thread is created the following > check is run: > ... [snip excellent example] ... >=20 > In the above the sunshine flow is that we get a boolean > value false, which means that two NoSuchMethodExceptions > are thrown. It seems that in connection with the reflection > API using the exceptions for business logic has become > the prefered idiom contrary to the advice. >=20 > But this is probably due to a lack of a better reflection > API. Or we can even analysis it deeper. Since the reflection > API methods can return so much information AND since java > does not have multi valued returns, the exceptions have > been abused for returning additional information. >=20 > In the Go Programming language one would do something: >=20 > getDeclaredMethod(String,Class[]) (Method,Error) >=20 > Shit happens! >=20 > P.S.: Actually the situation is worse in JDK 1.7, the > audit is done but then cached during the call of > isCCLOverridden(). This is good. But each call of > isCCLOverridden() does also poll the cache for > removal of inaccessible keys! Hm, not sure what > I should think about that. Excellent analysis and conclusions. In bringing up the rule "Use exceptions only for exceptional conditions" [/= op cit./] I omitted to mention another important rule, or set of rules: - There are no universal rules. and its corollaries/consequents,=20 - Rules were made to be broken. - The virtuoso knows when to break the rules. (The master creates the rule= s.) - The exception probes the rule. [original intent of the clich=E9 preserve= d] Like all the engineering decisions we make, the use of exceptions balances = alternatives. One could argue that the conditions you showed in your examp= le were "exceptional" enough to merit handling by exception. Pragmatically= , the alternatives suck by comparison anyway. Y'know, that motivating "exc= eptional conditions" clause leaves a whole lotta wiggle room. It's a common joke in engineering disciplines to issue harsh directives tha= t boil down to, "Do what thou wilt, but use good judgment." This does not = detract from the wisdom of the advice. --=20 Lew