Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I appreciate a lot the new Java 8 features about lambdas and default methods interfaces. Yet, I still get bored with checked exceptions. For instance, if I just want to list all the visible fields of an object I would like to simply write this:

        f -> System.out.println(f.get(p))

Yet, since the get method might throw a checked exception, which does not agrees with the Consumer interface contract, then I must catch that exception and write the following code:

            f -> {
                try {
                } catch (IllegalArgumentException | IllegalAccessException ex) {
                    throw new RuntimeException(ex);

However in most cases I just want the exception to be thrown as a RuntimeException and let the program handle, or not, the exception without compilation errors.

So, I would like to have your opinion about my controversial workaround for checked exceptions annoyance. To that end, I created an auxiliary interface ConsumerCheckException<T> and an utility function rethrow (updated according to the sugestion of Doval's comment) as follows:

  public interface ConsumerCheckException<T>{
      void accept(T elem) throws Exception;

  public class Wrappers {
      public static <T> Consumer<T> rethrow(ConsumerCheckException<T> c) {
        return elem -> {
          try {
          } catch (Exception ex) {
             * within sneakyThrow() we cast to the parameterized type T. 
             * In this case that type is RuntimeException. 
             * At runtime, however, the generic types have been erased, so 
             * that there is no T type anymore to cast to, so the cast
             * disappears.

       * Reinier Zwitserloot who, as far as I know, had the first mention of this
       * technique in 2009 on the java posse mailing list.
      public static <T extends Throwable> T sneakyThrow(Throwable t) {
          throw (T) t;

And now I can just write:

            rethrow(f -> System.out.println(f.get(p)))

I am not sure that this is the best idiom to turn around the checked exceptions, but as I explained, I would like to have a more convenient way of achieving my first example without dealing with checked exceptions and this is the simpler way that I found to do it.

share|improve this question
In addition to Robert's link, also take a look at Sneakily Throwing Checked Exceptions. If you wanted to, you could use sneakyThrow inside of rethrow to throw the original, checked exception instead of wrapping it in a RuntimeException. Alternatively you could use the @SneakyThrows annotation from Project Lombok that does the same thing. – Doval Jan 30 '14 at 4:10
Also note that the Consumers in forEach may be executed in parallel fashion when using parallel Streams. A throwable raised from withing the consumer will then propagate to the calling thread, which 1) won't stop the other concurrently running consumers, which may or may not be appropriate, and 2) if more than one of the consumers throw something, only one of the throwables will be seen by the calling thread. – Joonas Pulakka Feb 5 '14 at 8:10

5 Answers 5

In this example, can it ever really fail? Don't think so, but maybe your case is special. If it really "can't fail", and its just an annoying compiler thing, I like to wrap the exception and throw an Error with a comment "cannot happen". Makes things very clear for maintenance. Otherwise they will wonder "how can this happen" and "who the heck handles this?"

This in a controversial practice so YMMV. I'll probably get some downvotes.

share|improve this answer
+1 because you will throw an Error. How many times have I ended up after hours of debugging at a catch block containing just a single line comment "can't happen"... – Axel Jan 30 '14 at 13:31
-1 because you will throw an Error. Errors are to indicate that something is wrong in JVM and upper levels may handle them accordingly. If you choose that way, you should throw RuntimeException. Another possible workarounds are asserts (need -ea flag enabled) or logging. – duros Mar 28 '14 at 15:31
@duros: Depending upon why the exception "can't happen", the fact that it gets thrown may indicate that something is severely wrong. Suppose, for example, if one calls clone on a sealed type Foo which is known to support it, and it throws CloneNotSupportedException. How could that happen unless the code got linked with some other unexpected kind of Foo? And if that happens, can anything be trusted? – supercat Jul 9 '14 at 20:46
@supercat excellent example. Others are throwing exceptions from missing String Encodings or MessageDigests If UTF-8 or SHA are missing your runtime is likely corrupted. – user949300 Jul 10 '14 at 0:52

Advantages, disadvantages, and limitations of your technique:

• If the calling-code is to handle the checked exception you MUST add it to the throws clause of the method that contains the stream. The compiler will not force you to add it anymore, so it's easier to forget it. For example:

public void test(Object p) throws IllegalAccessException {
    Arrays.asList(p.getClass().getFields()).forEach(rethrow(f -> System.out.println(f.get(p))));

• If the calling-code already handles the checked exception, the compiler WILL remind you to add the throws clause to the method declaration that contains the stream (if you don't it will say: Exception is never thrown in body of corresponding try statement).

• In any case, you won't be able to surround the stream itself to catch the checked exception INSIDE the method that contains the stream (if you try, the compiler will say: Exception is never thrown in body of corresponding try statement).

• If you are calling a method which literally can never throw the exception that it declares, then you should not include the throws clause. For example: new String(byteArr, "UTF-8") throws UnsupportedEncodingException, but UTF-8 is guaranteed by the Java spec to always be present. Here, the throws declaration is a nuisance and any solution to silence it with minimal boilerplate is welcome.

• If you hate checked exceptions and feel they should never be added to the Java language to begin with (a growing number of people think this way, and I am NOT one of them), then just don't add the checked exception to the throws clause of the method that contains the stream. The checked exception will, then, behave just like an UNchecked exception.

• If you are implementing a strict interface where you don't have the option for adding a throws declaration, and yet throwing an exception is entirely appropriate, then wrapping an exception just to gain the privilege of throwing it results in a stacktrace with spurious exceptions which contribute no information about what actually went wrong. A good example is, which does not throw any checked exceptions. In this case, you may decide not to add the checked exception to the throws clause of the method that contains the stream.

• In any case, if you decide NOT to add (or forget to add) the checked exception to the throws clause of the method that contains the stream, be aware of these 2 consequences of throwing CHECKED exceptions:

1) The calling-code won't be able to catch it by name (if you try, the compiler will say: Exception is never thrown in body of corresponding try statement). It will bubble and probably be catched in the main program loop by some "catch Exception" or "catch Throwable", which may be what you want anyway.

2) It violates the principle of least surprise: it will no longer be enough to catch RuntimeException to be able to guarantee catching all possible exceptions. For this reason, I believe this should not be done in framework code, but only in business code that you completely control.

NOTE: If you decide to use this technique, you may copy the UtilException helper class from StackOverflow: . It gives you the complete implementation (Function, Consumer, Supplier...), with examples.

share|improve this answer

another version of this code where checked exception is just delayed :

public class Cocoon {
         static <T extends Throwable> T forgetThrowsClause(Throwable t) throws T{
            throw (T) t;

        public static <X, T extends Throwable> Consumer<X> consumer(PeskyConsumer<X,T> touchyConsumer) throws T {
            return new Consumer<X>() {
                public void accept(X t) {
                    try {
                    } catch (Throwable exc) {
                        Cocoon.<RuntimeException>forgetThrowsClause(exc) ;

            } ;
// and so on for Function, and other codes from java.util.function

the magic is that if you call:

 myArrayList.forEach(Cocoon.consumer(MyClass::methodThatThrowsException)) ;

then your code will be obliged to catch the exception

share|improve this answer
What happens if this is run on a parallel stream where elements are consumed in different threads? – prunge Jan 15 at 4:05

You may want to have a look at this project; I created it specifically because of the problem of checked exceptions and functional interfaces.

With it you can do this instead of writing your custom code:

// I don't know the type of f, so it's Foo...
final ThrowingConsumer<Foo> consumer = f -> System.out.println(f.get(p));

Since all those Throwing* interfaces extend their non Throwing counterparts, you can then use them directly in stream:


Or you can just:

import static com.github.fge.lambdas.consumers.Consumers.wrap;

    .forEach(wrap(f -> System.out.println(f.get(p)));

And other things.

share|improve this answer

Pointless discussion!

Checked exceptions are very useful and their handling depends on the kind of product you code is part of: -a library -a desktop application -a server running within some box -an academical exercise

Usually a library must not handle checked exceptions, but declare as thrown by public API. The rare case when they could wrapped into plain RuntimeExcepton is, for example, creating inside of library code some private xml document and parsing it, creating some temporary file and then reading that.

For desktop applications you must start the development of product by creating your own exception handling framework. Using you own framework usually you will wrap a checked exception into some of two to four wrappers (your custom sub-classes of RuntimeExcepion) and handle them by a single Exception Handler.

For servers usually your code will run inside of some framework. If you don't use any (a bare server) create your own framework similar (based on Runtimes) described above.

For academical exercises you can always wrap them directly into RuntimeExcepton. Somebody can create a tiny framework too.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.