Another question about functional interface and lambda: suppose we have
The above function interface means to open a file and do something within certain chars or length.. In my lambda code, I would do things like
Now, since it works with File, compiler would require you to catch certain exceptions.. But in the function interface, do we need to throw any Exception ? You know, sometimes the exception is really related to individual implementation, i.e. different lambda impl can generate diff exceptions. So, should we "throws..." in interface method at all ?
Post by:Jeanne Boyarsky
THis is one of the annoying thing with lambdas. You can't throw checked exceptions. So instead you need to have the implementation catch the checked exception and rethrow as a runtime exception.
Post by:Linwood Hayes
, Ranch Hand
Thanks Jeanne. I can understand that I let the code that enclosing lambda implementation do the try/catch stuff. But I don't understand why I need to re-throw it as Runtime exception ? why can't I just handle the checked exception ?
Post by:Linwood Hayes
, Ranch Hand
Linwood Hayes wrote:Thanks Jeanne. I can understand that I let the code that enclosing lambda implementation do the try/catch stuff. But I don't understand why I need to re-throw it as Runtime exception ? why can't I just handle the checked exception ?
Make it little clearer what I meant
Is this OK and good practice ?
Post by:Paul Clapham
Well, if your code can reasonably handle the exception (as opposed to just catching it and ignoring it) then yes, you can do that. But if a normal design would allow the method to throw that exception because it can't handle it, then your lambda's design should throw it too -- as a runtime exception.
Post by:Rob Spoor
Lambdas can throw checked exceptions, if the functional interface has defined it. For instance, if you tweak the extractFileData method a bit, it is now allowed to throw IOException:
I actually got so annoyed by the number of times I had to catch IOException and wrap it (in an UncheckedIOException, the best wrapper for IOExceptions since Java 8), I wrote a copy of all interfaces in java.util.function: https://robtimus.github.io/io-functions/. All can quite easily be converted to their equivalent in java.util.function using the provided unchecked methods.
There are basically three ways to deal with checked exceptions with lambdas: (1) put a try/catch block right inside the lambda, as you did, (2) create a method with a try/catch block with the code from the lambda and use a method reference to call it, or (3) write a wrapper method that catches all checked exceptions and re-throws them as unchecked. Approach (1) makes the stream pipeline hard to read. Approach (2) is pretty common. Approach (3) requires you to define your own functional interface that throws exception and write a method that returns one of the existing functional interfaces. I go through all three approaches in the book. Note that there are libraries, like VAVR, that try to do the last one for you.
The reason you can't just add a throws clause, though, is because the lambda is the implementation of the single abstract method in a functional interface, and you can't modify that method signature. Heck, you don't even see the method name when you write your lambda.
We're still dealing with several decisions made by the designers of Java at the birth of the language. Checked exceptions was one of them.
Post by:Stephan van Hulst
, Saloon Keeper
Kenneth A. Kousen wrote:We're still dealing with several decisions made by the designers of Java at the birth of the language. Checked exceptions was one of them.
You're saying that as if checked exceptions are a bad thing. I think it's one of the finest parts of the Java language. When I compare programs I've written in Java and programs I've written in C#, my Java programs are so much more robust because I'm forced to think about what I do with my exceptions.
I know that one of the designers wrote something along the lines of regretting adding checked exceptions to the language, but I believe they were on the right path.
You can create a language that very elegantly incorporates checked exceptions and lambda expressions, but your API must be designed with both features in mind.