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-exceptions-by.html > 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.
