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