Java 8 Lambda function that throws exception?
Asked Answered
G

28

640

I know how to create a reference to a method that has a String parameter and returns an int, it's:

Function<String, Integer>

However, this doesn't work if the function throws an exception, say it's defined as:

Integer myMethod(String s) throws IOException

How would I define this reference?

Gallon answered 12/8, 2013 at 23:16 Comment(5)
Related: #31638392Charming
...and this one: #31271259Morelos
github.com/TouK/ThrowingFunctionLandmeier
All the solution looks like some how, throwing Runtime exceptions, I belive it is not a good solution. so better to use old java for loopsEppes
What about jool library ? cf org.jooq.lambda.Unchecked packagePostliminy
B
566

You'll need to do one of the following.

  • If it's your code, then define your own functional interface that declares the checked exception:

    @FunctionalInterface
    public interface CheckedFunction<T, R> {
       R apply(T t) throws IOException;
    }
    

    and use it:

    void foo (CheckedFunction f) { ... }
    
  • Otherwise, wrap Integer myMethod(String s) in a method that doesn't declare a checked exception:

    public Integer myWrappedMethod(String s) {
        try {
            return myMethod(s);
        }
        catch(IOException e) {
            throw new UncheckedIOException(e);
        }
    }
    

    and then:

    Function<String, Integer> f = (String t) -> myWrappedMethod(t);
    

    or:

    Function<String, Integer> f =
        (String t) -> {
            try {
               return myMethod(t);
            }
            catch(IOException e) {
                throw new UncheckedIOException(e);
            }
        };
    
Beefburger answered 12/8, 2013 at 23:33 Comment(6)
Minor optimization: Instead of (String t) -> myWrappedMethod(t), the method reference this::myWrappedMethod can also be used.Eustis
Maybe a RuntimeException in place of UncheckedIOException would have been a better choice.Erfurt
An even more generic way to do it is to define the checked function like this @FunctionalInterface public interface CheckedFunction<T, R, E extends Exception> { R apply(T t) throws E; } In that way you can also define which exception that the function is throwing and can reuse the interface for any code.Wisteria
The second approach changes the exact class of the exception which may break code up higher that is catching that exact checked exception. See Brian Goetz answer on a similar question: https://mcmap.net/q/55724/-how-can-i-throw-checked-exceptions-from-inside-java-8-lambdas-streamsIronmonger
for me it worked passing an extra generic Exception argument to the interface definition: @FunctionalInterface public interface CheckedFunction<T, R, E extends Throwable> { R apply(T t) throws E; }Fanaticism
Converting a checked exception to a runtime exception is not a solution. It gets the code to compile, but ignores the error that's still thgere and will still cause the program to fail.Jurywoman
W
254

You can actually extend Consumer (and Function etc.) with a new interface that handles exceptions -- using Java 8's default methods!

Consider this interface (extends Consumer):

@FunctionalInterface
public interface ThrowingConsumer<T> extends Consumer<T> {

    @Override
    default void accept(final T elem) {
        try {
            acceptThrows(elem);
        } catch (final Exception e) {
            // Implement your own exception handling logic here..
            // For example:
            System.out.println("handling an exception...");
            // Or ...
            throw new RuntimeException(e);
        }
    }

    void acceptThrows(T elem) throws Exception;

}

Then, for example, if you have a list:

final List<String> list = Arrays.asList("A", "B", "C");

If you want to consume it (eg. with forEach) with some code that throws exceptions, you would traditionally have set up a try/catch block:

final Consumer<String> consumer = aps -> {
    try {
        // maybe some other code here...
        throw new Exception("asdas");
    } catch (final Exception ex) {
        System.out.println("handling an exception...");
    }
};
list.forEach(consumer);

But with this new interface, you can instantiate it with a lambda expression and the compiler will not complain:

final ThrowingConsumer<String> throwingConsumer = aps -> {
    // maybe some other code here...
    throw new Exception("asdas");
};
list.forEach(throwingConsumer);

Or even just cast it to be more succinct!:

list.forEach((ThrowingConsumer<String>) aps -> {
    // maybe some other code here...
    throw new Exception("asda");
});

Update

Looks like there's a very nice utility library part of Durian called Errors which can be used to solve this problem with a lot more flexibility. For example, in my implementation above I've explicitly defined the error handling policy (System.out... or throw RuntimeException), whereas Durian's Errors allow you to apply a policy on the fly via a large suite of utility methods. Thanks for sharing it, @NedTwigg!.

Sample usage:

list.forEach(Errors.rethrow().wrap(c -> somethingThatThrows(c)));
Wherein answered 2/12, 2014 at 14:46 Comment(4)
So you have a set of interfaces (Function, Consumer, Supplier, ...) and a set of policies for handling errors (Throwing, System.out.println, ...). I think there's a way to make it easy to use any policy with any kind of function, without having to copy paste "ThrowingConsumer, ThrowingFunction, etc.".Pliable
some time later... I decided to use unchecked exceptions and not use any additional functional interfaces or new libraries -> the easy road, less typing, faster delivery, isn't it.Slash
Here is an improved version using sneaky throwing idiom. No need to unwrap RuntimeException into CheckException.Bristletail
I prefer this approach instead of using library or other thing. Thank you anyway.Repletion
P
69

I think Durian's Errors class combines many of the pros of the various suggestions above.

To include Durian in your project, you can either:

Pliable answered 14/5, 2015 at 19:46 Comment(4)
Or you can just use RxJava since streams need inherent error handling and if there is something in your pipeline that throws an exception there is a good chance its probably an observable stream. This also doesn't force Java 8 on downstream consumers of a library.Luxe
Please note that Durian has no new versions since June 2016. Not a show stopper, but something to keep in mind.Jokester
Durian maintainer here. What's broken? If a user finds a bug or an important missing feature, we would release a bugfix quickly. The library is simple, thus we haven't had any bug reports, thus we haven't needed to release any bugfixes.Pliable
Please keep in mind that, currently, you need to copy more than "just two small classes".Mallina
V
33

This is not specific to Java 8. You are trying to compile something equivalent to:

interface I {
    void m();
}
class C implements I {
    public void m() throws Exception {} //can't compile
}
Valet answered 12/8, 2013 at 23:36 Comment(1)
The question is "How would I define this reference?". This doesn't actually answer the question; it just clarifies what the problem is.Malikamalin
T
14

Disclaimer: I haven't used Java 8 yet, only read about it.

Function<String, Integer> doesn't throw IOException, so you can't put any code in it that throws IOException. If you're calling a method that expects a Function<String, Integer>, then the lambda that you pass to that method can't throw IOException, period. You can either write a lambda like this (I think this is the lambda syntax, not sure):

(String s) -> {
    try {
        return myMethod(s);
    } catch (IOException ex) {
        throw new RuntimeException(ex);
        // (Or do something else with it...)
    }
}

Or, if the method you're passing the lambda to is one you wrote yourself, you can define a new functional interface and use that as the parameter type instead of Function<String, Integer>:

public interface FunctionThatThrowsIOException<I, O> {
    O apply(I input) throws IOException;
}
Trepidation answered 12/8, 2013 at 23:30 Comment(2)
add @FunctionalInterface annotation before your interface, only then it will be usable for lambdas.Ambry
@Gangnus: the @FunctionalInterface annotation is not required for it to be usable for lambdas. It is recommended for sanity check though.Mindoro
B
12

Sneaky throw idiom enables bypassing CheckedException of Lambda expression. Wrapping a CheckedException in a RuntimeException is not good for strict error handling.

It can be used as a Consumer function used in a Java collection.

Here is a simple and improved version of jib's answer.

import static Throwing.rethrow;

@Test
public void testRethrow() {
    thrown.expect(IOException.class);
    thrown.expectMessage("i=3");

    Arrays.asList(1, 2, 3).forEach(rethrow(e -> {
        int i = e.intValue();
        if (i == 3) {
            throw new IOException("i=" + i);
        }
    }));
}

This just wrapps the lambda in a rethrow. It makes CheckedException rethrow any Exception that was thrown in your lambda.

public final class Throwing {
    private Throwing() {}

    @Nonnull
    public static <T> Consumer<T> rethrow(@Nonnull final ThrowingConsumer<T> consumer) {
        return consumer;
    }

    /**
     * The compiler sees the signature with the throws T inferred to a RuntimeException type, so it
     * allows the unchecked exception to propagate.
     * 
     * http://www.baeldung.com/java-sneaky-throws
     */
    @SuppressWarnings("unchecked")
    @Nonnull
    public static <E extends Throwable> void sneakyThrow(@Nonnull Throwable ex) throws E {
        throw (E) ex;
    }

}

Find a complete code and unit tests here.

Bristletail answered 27/10, 2017 at 2:26 Comment(1)
From my point of view this is the most elegant solution without modifying original exception if you cannot not used lombok.Phan
U
11

If you don't mind to use a 3rd party lib (Vavr) you could write

CheckedFunction1<String, Integer> f = this::myMethod;

It also has the so-called Try monad which handles errors:

Try(() -> f.apply("test")) // results in a Success(Integer) or Failure(Throwable)
        .map(i -> ...) // only executed on Success
        ...

Please read more here.

Disclaimer: I'm the creator of Vavr.

Undamped answered 21/2, 2016 at 21:52 Comment(0)
D
7

You could however create your own FunctionalInterface that throws as below..

@FunctionalInterface
public interface UseInstance<T, X extends Throwable> {
  void accept(T instance) throws X;
}

then implement it using Lambdas or references as shown below.

import java.io.FileWriter;
import java.io.IOException;

//lambda expressions and the execute around method (EAM) pattern to
//manage resources

public class FileWriterEAM  {
  private final FileWriter writer;

  private FileWriterEAM(final String fileName) throws IOException {
    writer = new FileWriter(fileName);
  }
  private void close() throws IOException {
    System.out.println("close called automatically...");
    writer.close();
  }
  public void writeStuff(final String message) throws IOException {
    writer.write(message);
  }
  //...

  public static void use(final String fileName, final UseInstance<FileWriterEAM, IOException> block) throws IOException {

    final FileWriterEAM writerEAM = new FileWriterEAM(fileName);    
    try {
      block.accept(writerEAM);
    } finally {
      writerEAM.close();
    }
  }

  public static void main(final String[] args) throws IOException {

    FileWriterEAM.use("eam.txt", writerEAM -> writerEAM.writeStuff("sweet"));

    FileWriterEAM.use("eam2.txt", writerEAM -> {
        writerEAM.writeStuff("how");
        writerEAM.writeStuff("sweet");      
      });

    FileWriterEAM.use("eam3.txt", FileWriterEAM::writeIt);     

  }


 void writeIt() throws IOException{
     this.writeStuff("How ");
     this.writeStuff("sweet ");
     this.writeStuff("it is");

 }

}
Disk answered 30/5, 2015 at 22:48 Comment(0)
F
7

You can use unthrow wrapper

Function<String, Integer> func1 = s -> Unthrow.wrap(() -> myMethod(s));

or

Function<String, Integer> func2 = s1 -> Unthrow.wrap((s2) -> myMethod(s2), s1);
Fold answered 8/3, 2016 at 22:13 Comment(0)
M
6

You can.

Extending @marcg 's UtilException and adding generic <E extends Exception> where necessary: this way, the compiler will force you again to add throw clauses and everything's as if you could throw checked exceptions natively on java 8's streams.

public final class LambdaExceptionUtil {

    @FunctionalInterface
    public interface Function_WithExceptions<T, R, E extends Exception> {
        R apply(T t) throws E;
    }

    /**
     * .map(rethrowFunction(name -> Class.forName(name))) or .map(rethrowFunction(Class::forName))
     */
    public static <T, R, E extends Exception> Function<T, R> rethrowFunction(Function_WithExceptions<T, R, E> function) throws E  {
        return t -> {
            try {
                return function.apply(t);
            } catch (Exception exception) {
                throwActualException(exception);
                return null;
            }
        };
    }

    @SuppressWarnings("unchecked")
    private static <E extends Exception> void throwActualException(Exception exception) throws E {
        throw (E) exception;
    }

}

public class LambdaExceptionUtilTest {

    @Test
    public void testFunction() throws MyTestException {
        List<Integer> sizes = Stream.of("ciao", "hello").<Integer>map(rethrowFunction(s -> transform(s))).collect(toList());
        assertEquals(2, sizes.size());
        assertEquals(4, sizes.get(0).intValue());
        assertEquals(5, sizes.get(1).intValue());
    }

    private Integer transform(String value) throws MyTestException {
        if(value==null) {
            throw new MyTestException();
        }
        return value.length();
    }

    private static class MyTestException extends Exception { }
}
Megdal answered 22/6, 2015 at 8:36 Comment(0)
B
6

There are a lot of great responses already posted here. Just attempting to solve the problem with a different perspective. Its just my 2 cents, please correct me if I am wrong somewhere.

Throws clause in FunctionalInterface is not a good idea

I think this is probably not a good idea to enforce throws IOException because of following reasons

  • This looks to me like an anti-pattern to Stream/Lambda. The whole idea is that the caller will decide what code to provide and how to handle the exception. In many scenarios, the IOException might not be applicable for the client. For example, if the client is getting value from cache/memory instead of performing actual I/O.

  • Also, the exceptions handling in streams becomes really hideous. For example, here is my code will look like if I use your API

               acceptMyMethod(s -> {
                    try {
                        Integer i = doSomeOperation(s);
                        return i;
                    } catch (IOException e) {
                        // try catch block because of throws clause
                        // in functional method, even though doSomeOperation
                        // might not be throwing any exception at all.
                        e.printStackTrace();
                    }
                    return null;
                });
    

    Ugly isn't it? Moreover, as I mentioned in my first point, that the doSomeOperation method may or may not be throwing IOException (depending on the implementation of the client/caller), but because of the throws clause in your FunctionalInterface method, I always have to write the try-catch.

What do I do if I really know this API throws IOException

  • Then probably we are confusing FunctionalInterface with typical Interfaces. If you know this API will throw IOException, then most probably you also know some default/abstract behavior as well. I think you should define an interface and deploy your library (with default/abstract implementation) as follows

    public interface MyAmazingAPI {
        Integer myMethod(String s) throws IOException;
    }
    

    But, the try-catch problem still exists for the client. If I use your API in stream, I still need to handle IOException in hideous try-catch block.

  • Provide a default stream-friendly API as follows

    public interface MyAmazingAPI {
        Integer myMethod(String s) throws IOException;
    
        default Optional<Integer> myMethod(String s, Consumer<? super Exception> exceptionConsumer) {
            try {
                return Optional.ofNullable(this.myMethod(s));
            } catch (Exception e) {
                if (exceptionConsumer != null) {
                    exceptionConsumer.accept(e);
                } else {
                    e.printStackTrace();
                }
            }
    
            return Optional.empty();
        }
    }
    

    The default method takes the consumer object as argument, which will be responsible to handle the exception. Now, from client's point of view, the code will look like this

    strStream.map(str -> amazingAPIs.myMethod(str, Exception::printStackTrace))
                    .filter(Optional::isPresent)
                    .map(Optional::get).collect(toList());
    

    Nice right? Of course, logger or other handling logic could be used instead of Exception::printStackTrace.

  • You can also expose a method similar to https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html#exceptionally-java.util.function.Function- . Meaning that you can expose another method, which will contain the exception from previous method call. The disadvantage is that you are now making your APIs stateful, which means that you need to handle thread-safety and which will be eventually become a performance hit. Just an option to consider though.

Bollay answered 3/1, 2016 at 7:36 Comment(1)
I agree that converting the checked Exception to an unchecked Exception, or swallowing the Exception is not a good idea because there is no way to know which element of the Stream raised an Exception. Thus, I like the idea of having an exception handler and filtering the results that are not valid. Note that your MyAmazingAPI is effectively a FunctionalInterface (therefore you could add the @FunctionalInterface annotation). Also you could have a default value instead of using Optional.empty().Haste
B
5

Another solution using a Function wrapper would be to return either an instance of a wrapper of your result, say Success, if everything went well, either an instance of, say Failure.

Some code to clarify things :

public interface ThrowableFunction<A, B> {
    B apply(A a) throws Exception;
}

public abstract class Try<A> {

    public static boolean isSuccess(Try tryy) {
        return tryy instanceof Success;
    }

    public static <A, B> Function<A, Try<B>> tryOf(ThrowableFunction<A, B> function) {
        return a -> {
            try {
                B result = function.apply(a);
                return new Success<B>(result);
            } catch (Exception e) {
                return new Failure<>(e);
            }
        };
    }

    public abstract boolean isSuccess();

    public boolean isError() {
        return !isSuccess();
    }

    public abstract A getResult();

    public abstract Exception getError();
}

public class Success<A> extends Try<A> {

    private final A result;

    public Success(A result) {
        this.result = result;
    }

    @Override
    public boolean isSuccess() {
        return true;
    }

    @Override
    public A getResult() {
        return result;
    }

    @Override
    public Exception getError() {
        return new UnsupportedOperationException();
    }

    @Override
    public boolean equals(Object that) {
        if(!(that instanceof Success)) {
            return false;
        }
        return Objects.equal(result, ((Success) that).getResult());
    }
}

public class Failure<A> extends Try<A> {

    private final Exception exception;

    public Failure(Exception exception) {
        this.exception = exception;
    }

    @Override
    public boolean isSuccess() {
        return false;
    }

    @Override
    public A getResult() {
        throw new UnsupportedOperationException();
    }

    @Override
    public Exception getError() {
        return exception;
    }
}

A simple use case :

List<Try<Integer>> result = Lists.newArrayList(1, 2, 3).stream().
    map(Try.<Integer, Integer>tryOf(i -> someMethodThrowingAnException(i))).
    collect(Collectors.toList());
Beora answered 30/1, 2014 at 13:37 Comment(0)
S
5

I had this problem with Class.forName and Class.newInstance inside a lambda, so I just did:

public Object uncheckedNewInstanceForName (String name) {

    try {
        return Class.forName(name).newInstance();
    }
    catch (ClassNotFoundException | InstantiationException | IllegalAccessException e) {
        throw new RuntimeException(e);
    }
}

Inside the lambda, instead of calling Class.forName("myClass").newInstance() I just called uncheckedNewInstanceForName ("myClass")

Sailboat answered 17/1, 2015 at 12:21 Comment(0)
S
5

Create a custom return type that will propagate the checked exception. This is an alternative to creating a new interface that mirrors the existing functional interface with the slight modification of a "throws exception" on the functional interface's method.

Definition

CheckedValueSupplier

public static interface CheckedValueSupplier<V> {
    public V get () throws Exception;
}

CheckedValue

public class CheckedValue<V> {
    private final V v;
    private final Optional<Exception> opt;

    public Value (V v) {
        this.v = v;
    }

    public Value (Exception e) {
        this.opt = Optional.of(e);
    }

    public V get () throws Exception {
        if (opt.isPresent()) {
            throw opt.get();
        }
        return v;
    }

    public Optional<Exception> getException () {
        return opt;
    }

    public static <T> CheckedValue<T> returns (T t) {
        return new CheckedValue<T>(t);
    }

    public static <T> CheckedValue<T> rethrows (Exception e) {
        return new CheckedValue<T>(e);
    }

    public static <V> CheckedValue<V> from (CheckedValueSupplier<V> sup) {
        try {
            return CheckedValue.returns(sup.get());
        } catch (Exception e) {
            return Result.rethrows(e);
        }
    }

    public static <V> CheckedValue<V> escalates (CheckedValueSupplier<V> sup) {
        try {
            return CheckedValue.returns(sup.get());
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

}

Usage

//  Don't use this pattern with FileReader, it's meant to be an
//  example.  FileReader is a Closeable resource and as such should
//  be managed in a try-with-resources block or in another safe
//  manner that will make sure it is closed properly.

//  This will not compile as the FileReader constructor throws
//  an IOException.
    Function<String, FileReader> sToFr =
        (fn) -> new FileReader(Paths.get(fn).toFile());

// Alternative, this will compile.
    Function<String, CheckedValue<FileReader>> sToFr = (fn) -> {
        return CheckedValue.from (
            () -> new FileReader(Paths.get("/home/" + f).toFile()));
    };

// Single record usage
    // The call to get() will propagate the checked exception if it exists.
    FileReader readMe = pToFr.apply("/home/README").get();


// List of records usage
    List<String> paths = ...; //a list of paths to files
    Collection<CheckedValue<FileReader>> frs =
        paths.stream().map(pToFr).collect(Collectors.toList());

// Find out if creation of a file reader failed.
    boolean anyErrors = frs.stream()
        .filter(f -> f.getException().isPresent())
        .findAny().isPresent();

What's going on?

A single functional interface that throws a checked exception is created (CheckedValueSupplier). This will be the only functional interface which allows checked exceptions. All other functional interfaces will leverage the CheckedValueSupplier to wrap any code that throws a checked exception.

The CheckedValue class will hold the result of executing any logic that throws a checked exception. This prevents propagation of a checked exception until the point at which code attempts to access the value that an instance of CheckedValue contains.

The problems with this approach.

  • We are now throwing "Exception" effectively hiding the specific type originally thrown.
  • We are unaware that an exception occurred until CheckedValue#get() is called.

Consumer et al

Some functional interfaces (Consumer for example) must be handled in a different manner as they don't provide a return value.

Function in lieu of Consumer

One approach is to use a function instead of a consumer, which applies when handling streams.

    List<String> lst = Lists.newArrayList();
// won't compile
lst.stream().forEach(e -> throwyMethod(e));
// compiles
lst.stream()
    .map(e -> CheckedValueSupplier.from(
        () -> {throwyMethod(e); return e;}))
    .filter(v -> v.getException().isPresent()); //this example may not actually run due to lazy stream behavior

Escalate

Alternatively, you can always escalate to a RuntimeException. There are other answers that cover escalation of a checked exception from within a Consumer.

Don't consume.

Just avoid functional interfaces all together and use a good-ole-fashioned for loop.

Spoken answered 30/8, 2016 at 14:44 Comment(0)
D
4

This problem has been bothering me as well; this is why I have created this project.

With it you can do:

final ThrowingFunction<String, Integer> f = yourMethodReferenceHere;

There are a totla of 39 interfaces defined by the JDK which have such a Throwing equivalent; those are all @FunctionalInterfaces used in streams (the base Stream but also IntStream, LongStream and DoubleStream).

And as each of them extend their non throwing counterpart, you can directly use them in lambdas as well:

myStringStream.map(f) // <-- works

The default behavior is that when your throwing lambda throws a checked exception, a ThrownByLambdaException is thrown with the checked exception as the cause. You can therefore capture that and get the cause.

Other features are available as well.

Dewdrop answered 29/12, 2014 at 22:0 Comment(5)
I really like the idea, I only wish you made the throwables generic as suggested here: javaspecialists.eu/archive/Issue221.html, e.g.: @FunctionalInterface public interface SupplierWithCE<T, X extends Exception> { T get() throws X; } - this way the user doesn't need to catch Throwable, but the specific checked exception instead.Bearskin
@Zoltán that would be a pain to declare the exception each and every time though; also, you can always just use, say, .apply() instead of .doApply() and catch ThrownByLambdaException, you'll have the original exception as a cause (or you can use rethrow(...).as(MyRuntimeException.class))Dewdrop
I think there is (kind of) a way around this.Pliable
@NedTwigg I have solved this long ago as well; I can now use Throwing.runnable() and others, always with chaining capabilitiesDewdrop
The chaining functionality is very cool! My comment was about whether ThrowingRunnable should have the generic exception or not. Zoltan asked if your library could have the argument as a generic parameter, and you said that would be a pain to use. My link was to some lines of code which show one way to have the exceptions be generic, without it being a pain. Unless I misread it, the exceptions in your library are not generic (which is a reasonable design choice, because you don't get much utility by making them generic).Pliable
S
4

By default, Java 8 Function does not allow to throw exception and as suggested in multiple answers there are many ways to achieve it, one way is:

@FunctionalInterface
public interface FunctionWithException<T, R, E extends Exception> {
    R apply(T t) throws E;
}

Define as:

private FunctionWithException<String, Integer, IOException> myMethod = (str) -> {
    if ("abc".equals(str)) {
        throw new IOException();
    }
  return 1;
};

And add throws or try/catch the same exception in caller method.

Strasbourg answered 13/2, 2017 at 8:34 Comment(0)
R
4

I use an overloaded utility function called unchecked() which handles multiple use-cases.


SOME EAMPLE USAGES

unchecked(() -> new File("hello.txt").createNewFile());

boolean fileWasCreated = unchecked(() -> new File("hello.txt").createNewFile());

myFiles.forEach(unchecked(file -> new File(file.path).createNewFile()));

SUPPORTING UTILITIES

public class UncheckedUtils {

    @FunctionalInterface
    public interface ThrowingConsumer<T> {
        void accept(T t) throws Exception;
    }

    @FunctionalInterface
    public interface ThrowingSupplier<T> {
        T get() throws Exception;
    }

    @FunctionalInterface
    public interface ThrowingRunnable {
        void run() throws Exception;
    }

    public static <T> Consumer<T> unchecked(
            ThrowingConsumer<T> throwingConsumer
    ) {
        return i -> {
            try {
                throwingConsumer.accept(i);
            } catch (Exception ex) {
                throw new RuntimeException(ex);
            }
        };
    }

    public static <T> T unchecked(
            ThrowingSupplier<T> throwingSupplier
    ) {
        try {
            return throwingSupplier.get();
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    }

    public static void unchecked(
            ThrowingRunnable throwing
    ) {
        try {
            throwing.run();
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    }
}
Reproduction answered 20/1, 2020 at 13:27 Comment(0)
R
4

If using Java 8 Function interface is not a requirement, Apache Commons library offers an alternative FailableFunction interface to address this issue since release 3.11 - https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/function/FailableFunction.html

Here is how it can be used -

Integer myMethod(String s) throws IOException;

FailableFunction<String, Integer, IOException> function = this::myMethod;

Integer result;
try {
    result = function.apply(s);
} catch (IOException ex) {
    // Handle the exception
}

Check complete list of alternative Failable interfaces on following page - https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/function/package-summary.html

Regenaregency answered 20/6, 2023 at 11:51 Comment(0)
S
3

You can use ET for this. ET is a small Java 8 library for exception conversion/translation.

With ET it looks like this:

// Do this once
ExceptionTranslator et = ET.newConfiguration().done();

...

// if your method returns something
Function<String, Integer> f = (t) -> et.withReturningTranslation(() -> myMethod(t));

// if your method returns nothing
Consumer<String> c = (t) -> et.withTranslation(() -> myMethod(t));

ExceptionTranslator instances are thread safe an can be shared by multiple components. You can configure more specific exception conversion rules (e.g. FooCheckedException -> BarRuntimeException) if you like. If no other rules are available, checked exceptions are automatically converted to RuntimeException.

(Disclaimer: I am the author of ET)

Starchy answered 2/9, 2015 at 18:4 Comment(0)
U
3

If you don't mind using a third party library, with cyclops-react, a library I contribute to, you can use the FluentFunctions API to write

 Function<String, Integer> standardFn = FluentFunctions.ofChecked(this::myMethod);

ofChecked takes a jOOλ CheckedFunction and returns the reference softened back to a standard (unchecked) JDK java.util.function.Function.

Alternatively you can keep working with the captured function via the FluentFunctions api!

For example to execute your method, retrying it up to 5 times and logging it's status you can write

  FluentFunctions.ofChecked(this::myMethod)
                 .log(s->log.debug(s),e->log.error(e,e.getMessage())
                 .try(5,1000)
                 .apply("my param");
Undergraduate answered 24/2, 2016 at 15:56 Comment(0)
L
2

What I'm doing is to allow the user to give the value he actually want in case of exception . So I've something looking like this

public static <T, R> Function<? super T, ? extends R> defaultIfThrows(FunctionThatThrows<? super T, ? extends R> delegate, R defaultValue) {
    return x -> {
        try {
            return delegate.apply(x);
        } catch (Throwable throwable) {
            return defaultValue;
        }
    };
}

@FunctionalInterface
public interface FunctionThatThrows<T, R> {
    R apply(T t) throws Throwable;
}

And this can then be call like :

defaultIfThrows(child -> child.getID(), null)
Lhasa answered 30/9, 2014 at 12:37 Comment(1)
This is an extension of this idea which makes a distinction between a "default value" strategy (as in your answer), and a "rethrow RuntimeException" strategy, where a default value isn't necessary.Pliable
E
2

Use Jool Library or say jOOλ library from JOOQ. It not only provides unchecked exception handled interfaces but also provides Seq class with lots of useful methods.

Also, it contains Functional Interfaces with up to 16 parameters. Also, it provides Tuple class which is used in different scenarios.

Jool Git Link

Specifically in library lookup for org.jooq.lambda.fi.util.function package. It contains all the Interfaces from Java-8 with Checked prepended. See below for reference:-

enter image description here

Extracurricular answered 12/12, 2017 at 9:16 Comment(1)
Here's a blog post showing examples of how that works in jOOλ: blog.jooq.org/…Streetcar
D
2

If you have lombok, you can annotate your method with @SneakyThrows

SneakyThrow does not silently swallow, wrap into RuntimeException, or otherwise modify any exceptions of the listed checked exception types. The JVM does not check for the consistency of the checked exception system; javac does, and this annotation lets you opt out of its mechanism.

https://projectlombok.org/features/SneakyThrows

Diameter answered 28/9, 2020 at 23:38 Comment(1)
Amazing. I loved it. It allows you to throw checked exceptions without using the throws declaration. Quite useful when you are passing function to Lambda. baeldung.com/java-sneaky-throwsSemimonthly
K
0

Several of the offered solutions use a generic argument of E to pass in the type of the exception which gets thrown.

Take that one step further, and rather than passing in the type of the exception, pass in a Consumer of the type of exception, as in...

Consumer<E extends Exception>

You might create several re-usable variations of Consumer<Exception> which would cover the common exception handling needs of your application.

Katerine answered 12/6, 2017 at 16:7 Comment(0)
L
0

I will do something generic:

public interface Lambda {

    @FunctionalInterface
    public interface CheckedFunction<T> {

        T get() throws Exception;
    }

    public static <T> T handle(CheckedFunction<T> supplier) {
        try {
            return supplier.get();
        } catch (Exception exception) {
            throw new RuntimeException(exception);

        }
    }
}

usage:

 Lambda.handle(() -> method());
Lichfield answered 21/7, 2017 at 11:23 Comment(0)
P
0

I'm the author of a tiny lib with some generic magic to throw any Java Exception anywhere without the need of catching them nor wrapping them into RuntimeException.

Usage: unchecked(() -> methodThrowingCheckedException())

public class UncheckedExceptions {

    /**
     * throws {@code exception} as unchecked exception, without wrapping exception.
     *
     * @return will never return anything, return type is set to {@code exception} only to be able to write <code>throw unchecked(exception)</code>
     * @throws T {@code exception} as unchecked exception
     */
    @SuppressWarnings("unchecked")
    public static <T extends Throwable> T unchecked(Exception exception) throws T {
        throw (T) exception;
    }


    @FunctionalInterface
    public interface UncheckedFunction<R> {
        R call() throws Exception;
    }

    /**
     * Executes given function,
     * catches and rethrows checked exceptions as unchecked exceptions, without wrapping exception.
     *
     * @return result of function
     * @see #unchecked(Exception)
     */
    public static <R> R unchecked(UncheckedFunction<R> function) {
        try {
            return function.call();
        } catch (Exception e) {
            throw unchecked(e);
        }
    }


    @FunctionalInterface
    public interface UncheckedMethod {
        void call() throws Exception;
    }

    /**
     * Executes given method,
     * catches and rethrows checked exceptions as unchecked exceptions, without wrapping exception.
     *
     * @see #unchecked(Exception)
     */
    public static void unchecked(UncheckedMethod method) {
        try {
            method.call();
        } catch (Exception e) {
            throw unchecked(e);
        }
    }
}

source: https://github.com/qoomon/unchecked-exceptions-java

Periodontal answered 4/1, 2019 at 13:32 Comment(0)
G
0

For me the preferred solution is to use Lombok. It is a nice library anyway.

Instead of:

Integer myMethod(String s) throws IOException

you will have

import lombok.SneakyThrows;

@SneakyThrows
Integer myMethod(String s)

The exception is still thrown but you do not need to declare it with throws.

Glandulous answered 22/6, 2022 at 12:6 Comment(0)
P
-9
public void frankTest() {
    int pageId= -1;

    List<Book> users= null;
    try {
        //Does Not Compile:  Object page=DatabaseConnection.getSpringConnection().queryForObject("SELECT * FROM bookmark_page", (rw, n) -> new Portal(rw.getInt("id"), "", users.parallelStream().filter(uu -> uu.getVbid() == rw.getString("user_id")).findFirst().get(), rw.getString("name")));

        //Compiles:
        Object page= DatabaseConnection.getSpringConnection().queryForObject("SELECT * FROM bookmark_page", (rw, n) -> { 
            try {
                final Book bk= users.stream().filter(bp -> { 
                    String name= null;
                    try {
                        name = rw.getString("name");
                    } catch (Exception e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                    }
                    return bp.getTitle().equals(name); 
                }).limit(1).collect(Collectors.toList()).get(0);
            } catch (Exception e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            return new Portal(rw.getInt("id"), "", users.get(0), rw.getString("name")); 
        } );
    } catch (Exception e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}
Provincial answered 9/1, 2015 at 16:37 Comment(2)
Mind to comment your work? Code-only answers aren't so useful.Wun
@Franky you can fix your presentation by use 4 spacing, instead of <code>/<code> :)Reaction

© 2022 - 2024 — McMap. All rights reserved.