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)
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.
