I'll one up y'all:

public class Sneak {
        public static RuntimeException sneakyThrow(Throwable t) {
                if ( t == null ) throw new NullPointerException("t");
                return null;

        private static <T extends Throwable> void sneakyThrow0(Throwable t)
throws T {
                throw (T)t;

There is absolutely no point in wrapping everything into a gazillion
layers of exceptions - that just results in 10 pages of stacktrace to
walk through. Preferably, all your classes throw the exceptions they
cause, but if interface restrictions are preventing you from sticking
'throws SQLException' in the appropriate places, use this. Don't wrap
unless there's a good reason for it. A good reason would be if e.g. a
database abstraction layer has its own 'DataSourceException', and a
specific implementation that works with files wraps
FileNotFoundExceptions in DataSourceExceptions. That's useful
wrapping. turning everything into 'MyRuntimeException' is a waste of

Or, of course, use project lombok and add "@SneakyThrows
(SQLException.class)" to your method, which saves you a try/catch

On Aug 15, 5:22 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
> Casper Bang wrote:
> > Hehe that's a big can of worms to open up in here, but I do the same.
> I too have some rough code that does exception handling for
> transactions, to decide whether to retry or abort.
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -www.tidalwave.it/blog
> fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to