Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8457
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Avoid creating a stacktrace prior to JDK 1.7 |
| Date | 2011-10-01 12:21 -0700 |
| Organization | http://groups.google.com |
| Message-ID | <1058576.2212.1317496868028.JavaMail.geo-discussion-forums@prfh23> (permalink) |
| 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> |
Jan Burse wrote: > Lew schrieb: >> in the first place. >> >> /Effective Java/, Joshua Bloch, "Item 57: Use exceptions only for exceptional conditions". > > The JDK itself violates this rule. For example > each time a Thread is created the following > check is run: > ... [snip excellent example] ... > > 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. > > 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. > > In the Go Programming language one would do something: > > getDeclaredMethod(String,Class[]) (Method,Error) > > Shit happens! > > 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, - Rules were made to be broken. - The virtuoso knows when to break the rules. (The master creates the rules.) - The exception probes the rule. [original intent of the cliché preserved] Like all the engineering decisions we make, the use of exceptions balances alternatives. One could argue that the conditions you showed in your example were "exceptional" enough to merit handling by exception. Pragmatically, the alternatives suck by comparison anyway. Y'know, that motivating "exceptional conditions" clause leaves a whole lotta wiggle room. It's a common joke in engineering disciplines to issue harsh directives that boil down to, "Do what thou wilt, but use good judgment." This does not detract from the wisdom of the advice. -- Lew
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-09-30 15:57 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 13:27 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 13:22 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 09:10 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:31 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:02 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 12:21 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 22:04 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 16:24 -0400
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 23:14 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-01 17:28 -0400
Re: Avoid creating a stacktrace prior to JDK 1.7 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-01 23:45 +0000
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 00:58 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 02:04 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-01 20:06 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-02 13:14 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Lew <lewbloch@gmail.com> - 2011-10-02 08:37 -0700
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-02 20:26 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-02 17:51 -0400
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-03 01:32 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 20:19 +0300
Re: Avoid creating a stacktrace prior to JDK 1.7 Jan Burse <janburse@fastmail.fm> - 2011-10-01 20:04 +0200
Re: Avoid creating a stacktrace prior to JDK 1.7 Stanimir Stamenkov <s7an10@netscape.net> - 2011-10-01 21:15 +0300
csiph-web