On 24 Mar 2011 13:09, "Phil" <[email protected]> wrote: > > This is a discussion about Java exception handling, so any suggestion > to avoid it by using another language can't really be viewed as > anything but flippant... (whispers - or trolling) >
"Java" is a platform, not just a language... > On Mar 24, 1:03 pm, Kevin Wright <[email protected]> wrote: > > On 24 March 2011 11:41, Reinier Zwitserloot <[email protected]> wrote: > > > > > > > > > Neither of these strategies works well. > > > > > The wrap-into-RuntimeException model means you're chasing down 'causes' > > > EVERYWHERE - even runtimeexceptions are themselves wrapped in more > > > runtimeexceptions. You can avoid some of this by catching RuntimeException > > > separately and throwing them without wrapping, but you're still effectively > > > eliminating the utility of stack traces. > > > > > The "throws Exception" strategy cannot be combined when implementing any > > > number of oft-implemented interfaces, such as Runnable. > > > > > The proper solution if you really dislike checked exceptions is > > > sneakythrows. James Iry's blogpost (as posted earlier, but here it is again, > > > without expected and ridiculously annoying flippant "Use Scala" commentary > > > by KevinBot): > > >http://james-iry.blogspot.com/2010/08/on-removing-java-checked-except. .. > > > > Flappant would be to state "use Haskell", or Coq, or Agda. By comparison, > > Scala is significantly more acceptable to many Java developers, especially > > if you're already considering a tool like Lombok that will break code on any > > existing IDEs without the plugin. If you're having to download special > > support for your IDE & build tools anyway, then you're already halfway to a > > different language, Lombok and Scala have exactly the same ease of adding to > > your toolchain (except for IntelliJ, which Lombok doesn't support) > > > > Scala *is* relevant here, as is any language offering built-in support for > > Either/Maybe/Whatever - allowing a method to return one of two possible > > types. Either the result of some successful operation or some indication of > > error. Use closures to repeatedly map over the success values contained in > > this construct and you have a very clean, composable way to represent > > problems that aren't exactly "exceptional". Unlike checked exceptions > > (which can be subverted), this approach truly does force callers to > > acknowledge the possible error condition, and does so with far less ceremony > > and potential for abuse. It's possible to use a similar approach in Java, > > though the lack of consistent library support and closures is obviously > > going to make it harder. Another tactic is also create Null objects, or > > Error objects, subclasses of the expected return type that express a failure > > without having to pervert flow control. > > > > You often give the impression of critiquing Scala simply because it > > threatens your own library, and I'd hate to see someone with your > > technical achievements being ultimately judged as a fearmonger. While > > competition is natural and healthy, FUD is good for nobody. I have yet to > > see a Scala advocate showing anything but praise for your efforts with > > Lombok, so it's only polite to stop firing off nothing but objections in > > response. > > > > You can also use Lombok and either add @SneakyThrows or if thats too much > > > > > magic for you, write this: > > > > > try { > > > .. do whatever > > > } catch (Exception e) { > > > throw Lombok.sneakyThrow(e); > > > } > > > > > which does NOT wrap exceptions but DOES eliminate all need to deal with > > > them (I'm not advocating that the blanket treatment of all checked > > > exceptions as misguided is a good idea, but Cedric's already done a decent > > > job of explaining this). With the lombok 0.10.0 beta, the dependency on > > > Lombok at runtime will be eliminated via class file rewriting automatically. > > > Otherwise, all you actually need at runtime is Lombok.class. > > > > > I can't stress enough how important it is to manage your APIs properly. > > > Checked exceptions can be a good thing but most libraries I know (primary > > > offender is java's runtime itself!) throw _WAY_ too many checked exceptions. > > > IOException should have been unchecked, because there are many, many > > > situations where you just can't do anything about it. Think of your > > > consumers: If either (A) there are a significant number of situations where > > > that exception is effectively not going to happen anyway, i.e. with > > > InputStream.close(), don't make it checked. If (B) There are significant use > > > cases where there's nothing useful to do for any part of a large chain, > > > other than the very top (servlets, db failures, threads), don't make it > > > checked. > > > > > Also be consistent. IOException being checked and NumberFormatException > > > being unchecked is ridiculous, it's the same situation, and arguably NFEx is > > > easier to handle than IOException (you can ask a user to re-enter a number. > > > It's kinda hard to ask a filesystem to try harder). > > > > So checked exceptions are a good thing, but only if we, the users, develop > > the core Java APIs better in the first place? Don't ask for much, do you? > > > > > Finally, check your interfaces. Runnable's run should OF COURSE have > > > included "throws Exception". Runnable's designed use is for threads, and > > > Thread will (of course) handle any and all exceptions that leak through via > > > the unhandledExceptionHandler. We're all jumping through hoops because of > > > these brainfarts. Take more care when you write your own libraries. > > > > > -- > > > 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. > -- 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.
