The argument boils down to to costs vs benefits.
All the checked exception haters think the costs greatly out-weigh the
benefits.
Costs:
1) PITA
2) Your interfaces break every time you introduce a new exception.
3) They don't scale (rippling effect can easily get out of hand)
That and lead to a bunch of people writing code like this (We've all seen
it):
try {...}
catch(Excpetion e)
{Log.exception(e)}
or
try {...}
catch(Excpetion e)
{// empty clause}
The former is usually wrong in that you usually can't proceed as if
everything is OK.
The latter speaks for itself.
And the Benefits?
meh.
2011/3/23 Cédric Beust ♔ <[email protected]>
>
>
> 2011/3/23 phil swenson <[email protected]>
>
>> Thanks for the Lazy comment. You can handle Exceptions even if they are
>> RuntimeExceptions
>>
>
> Of course, but since the compiler no longer enforces it, they are easy to
> miss and to ignore. I much prefer the compiler getting into my face to
> remind me "this call can fail this way and that way, and you need to think
> about this right now".
>
> Note that you only need to "think" about it. Once you do that, you decide
> if you want to handle it or defer it to callers. It's a very sane way of
> building solid code.
>
>
>
>> (just like you do in every language ever created other than Java).
>> Usually you want to let them bubble up, so it's very annoying to have to
>> deal with them at every level up the stack.
>>
>
> Yes, it is annoying to handle error cases, but you have to. Besides, you
> only need to deal with it at the level you choose. Wherever you don't care
> about them or can't handle them, just add a `throws` clause. That's the
> right way of doing it.
>
> The wrong way is adding `throws` everywhere, because with this system, all
> your methods end up declaring an exception, which means that in effect, none
> of them do. Effectively, you have just completely disabled the exception
> system and all the advantages that they bring.
>
>
>
>> No one is arguing against ever handling exceptions.
>>
>> See this: http://www.artima.com/intv/handcuffs.html
>> or this: http://www.mindview.net/Etc/Discussions/CheckedExceptions
>> or this:
>> http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
>>
>> I'm reading Robert C.
>> Martin<http://www.amazon.com/Robert-C.-Martin/e/B000APG87E/ref=sr_ntt_srch_lnk_1?qid=1300922689&sr=8-1>'s
>> (Uncle Bob) "Clean Code" right now and I actually was surprised almost every
>> code example he gives says "throws Exception".
>>
>
> Yes, it's always baffled me that someone who claims to feel so strongly
> about "clean code" is so cavalier and dismissive about error cases.
>
> It's a similar argument to the one presented in the blog post: the code
> "looks" clean, but it's not robust.
>
>
>
>> But he does go on a rant against CheckedExceptions in the book so I guess
>> he's just in the "throws Exception" camp as a solution to the problem.
>>
>
> Yup. He just doesn't understand checked exceptions, like so many other
> people.
>
> The important part is understanding that you need both runtime and checked
> exceptions. The hard part is knowing when to choose "checked", and the
> authors of the JDK made some terrible mistakes in that area which have given
> the entire concept a very bad reputation.
>
>
>
>>
>> I also just found this snippet for what Bruce Eckel advocates (from
>> http://www.ibm.com/developerworks/library/j-jtp05254.html#resources):
>>
>
> Same observation about Bruce, who's gone much further down the rabbit hole
> and who's now advocating that types are a hindrance.
>
> --
> Cédric
>
>
>
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
