It's quite simple... If there's something that can happen in your method, and the caller *explicitly* needs to deal with it, then there's a technique for dealing with that... It's commonly known as a "return value". Yes, some form of "Maybe" or "Either" type combined with lambdas makes this sort of thing a lot more concise and readable, but it's certainly doable in Java, and the language isn't exactly a stranger to boilerplate and verbosity!
If it's possible that an unexpected, *exceptional* fault may occur, and the method really has no idea about how far up the call stack you should go before it can be correctly handled, then throw an exception, but please don't expect every possible intervening method to encapsulate this possibility in its type signature. There is no place for checked exceptions, they only appear to have value in the most trivial of examples, purpose-crafted to demonstrate the concept. 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 > > > > > > -- > 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. > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
