{"id":81,"date":"2020-12-27T13:16:55","date_gmt":"2020-12-27T11:16:55","guid":{"rendered":"http:\/\/victorrentea.ro\/blog\/?p=81"},"modified":"2020-12-31T07:47:42","modified_gmt":"2020-12-31T05:47:42","slug":"exceptions-and-streams","status":"publish","type":"post","link":"https:\/\/victorrentea.ro\/blog\/exceptions-and-streams\/","title":{"rendered":"Exceptions and Streams"},"content":{"rendered":"
<\/div>

Java 8 gave us Optional<\/code>, a mighty weapon against the most frequent Exception in Java: NullPointerException<\/code>, that I talked about in this blog post<\/a>. However, Java 8 also brought new headaches regarding exceptions, as the default functional interfaces in Java 8 don\u2019t declare throwing any checked exceptions. So usually when you get a checked exception within a lambda, you have to fix that somehow.<\/p>\n

Converting Checked into Runtime Exceptions<\/h2>\n

The default suggestion offered by most IDEs to auto-fix this issue will produce code like this:<\/p>\n

SimpleDateFormat format = new SimpleDateFormat(\"yyyy-MM-dd\");<\/code>\nList<String> dateList = asList(\"2020-10-11\", \"2020-nov-12\", \"2020-12-01\");<\/code>\nList<Date> dates = dateList.stream().map(s -> {<\/code>\n   try {<\/code>\n      return format.parse(s);<\/code>\n   } catch (ParseException e) {<\/code>\n      throw new RuntimeException(e);<\/code>\n   }<\/code>\n}).collect(toList());<\/code><\/pre>\n
Horrible code.<\/p>\n
We could create a dedicated function doing just .parse<\/code> and then cast a spell on it with @SneakyThrows<\/code>, as we’ve discussed in a previous article<\/a>:<\/p>\n
   List<Date> dates = dateList.stream()<\/code>\n        .map(s -> uglyParse(format, s))<\/code>\n        .collect(toList());<\/code>\n   ...<\/code>\n}<\/code><\/pre>\n
@SneakyThrows<\/code>
\nprivate static Date uglyParse(SimpleDateFormat format, String s) {<\/code>
\n   return format.parse(s);<\/code>
\n}<\/code><\/p>\n
But creating this new method just to hack it with Lombok feels wrong. Indeed, we created it for a purely technical reason: to hide the annoying checked exception which doesn’t fit with the java.util.Function<\/code> interface that doesn’t declare throwing anything.<\/p>\n
Let’s play a bit and create a ThrowingFunction<\/code> interface declaring to throw any checked exception:<\/p>\n
interface ThrowingFunction<T,R> {<\/code>\n    R apply(T t) throws Exception;<\/code>\n}<\/code><\/pre>\n
Then, our s->format.parse(s)<\/code> expression could be target-typed<\/a> to this new interface, so the following line compiles:<\/p>\n
ThrowingFunction<String, Date> p = s -> format.parse(s);<\/code>\n\/\/ or<\/code>\nThrowingFunction<String, Date> p = format::parse;<\/code><\/pre>\n
Unfortunately, the Stream.map()<\/code> operation takes a java.util.function.Function<\/code>. You can’t change that, but let’s imagine we had a function that would take a ThrowingFunction<\/code> and return back a ‘classic’ java.util.function.Function<\/code> that doesn’t throw any checked exception anymore.<\/p>\n
Function<String, Date> f = wrapAsRuntime(p);<\/code>\nList<Date> dates = dateList.stream().map(f).collect(toList());<\/code><\/pre>\n
And here’s the strange wrapAsRuntime<\/code> function:<\/p>\n
private static <T,R> Function<T, R> wrapAsRuntime(ThrowingFunction<T, R> p) {<\/code>\n    return t -> {<\/code>\n        try {<\/code>\n            return p.apply(t);<\/code>\n        } catch (Exception e) {<\/code>\n            throw new RuntimeException(e);<\/code>\n        }<\/code>\n    };<\/code>\n}<\/code><\/pre>\n
If that’s complete nonsense for your, then I would advice that you try to type it yourself. It helps a lot!<\/p>\n
Notice that we\u2019ve used generics to make it highly reusable. That’s quite a good idea, isnt’it? It’s so good that of course others had it it many years ago… \ud83d\ude42<\/p>\n
Introducing the Unchecked.function()<\/code> from the jool library<\/a> that does EXACTLY what we did above. Using it, the final code looks like:<\/p>\n
List<Date> dates = dateList.stream().map(Unchecked.function(format::parse)).collect(toList());<\/code><\/pre>\n
If you’ve been using Java 8 for many years, then this library is a must-have.<\/p>\n
Best-practice<\/strong>: Whenever checked exceptions are annoying you in lambdas -><\/code> or method references ::<\/code>, use Unchecked.*<\/code> to rethrow it as a RuntimeException<\/code><\/p><\/blockquote>\n
This doesn’t involve any hack in the bytecode (as @SneakyThrows does<\/a>), but only plain java code. Passing a function as a parameter to another function is a very useful practice that I will be blogging about soon, but functions that both take and return functions – I found that the vast majority of developers have a hard time reasoning about them. It’s one of the most complex, hard to read, and especially hard to debug in Java, so avoid mixing it with complex business logic. But since it’s a library doing it, and the purpose is straightforward, I never hesitated to use it many of my projects. On the other hand, if you want to avoid depending on this library, you just saw the necessary code to write.<\/p>\n
Now let’s shift a bit the perspective. No matter how you twist it, the processing of the entire stream stops when the first exception is thrown. But what if we don’t want to crash but instead collect all the errors.<\/p>\n
The Try Monad<\/h2>\n
Let\u2019s change the requirements a bit: we now want to parse all the valid<\/strong> dates and return them IF at least half of them are parseable, otherwise we should throw an exception. This time we can\u2019t let an exception terminate the execution of our stream. Instead, we want to go through all of the items and collect both parsed dates and exceptions. For example, if we are given 3 correctly-formatted dates and 2 invalid ones, we should return the 3 ones that we were able to parse correctly.<\/p>\n
Whenever you want to collect the exceptions<\/strong> happening in items, consider using the vavr Try<\/code> monad.<\/p><\/blockquote>\n
The Try<><\/code> class from the vavr library<\/a> is a specialization of the Either<><\/code> concept present in many functional programming languages. An instance can store either the result or the occurred exception (if any).<\/p>\n
List<Try<Date>> tries = dateList.stream()<\/code>\n    .map(s -> Try.of(<\/code>\n        () -> format.parse(s) \/\/ throwing code<\/code>\n    ))<\/code>\n    .collect(toList());<\/code><\/pre>\n
If the throwing code<\/em> crashes with an exception, the surrounding Try.of<\/code> function will catch that exception and return a failed Try<\/strong>. Therefore, in the tries<\/code> list above, there can be items with isSuccess()<\/code> either true<\/code> or false<\/code>. To count the success ratio, the shortest (geekest) form is:<\/p>\n
double successRatio = tries.stream()<\/code>\n    .mapToInt(t -> t.isSuccess() ? 1 : 0)<\/code>\n    .average()<\/code>\n    .orElse(0);<\/code><\/pre>\n
Then,<\/p>\n
if (successRatio > .5) {<\/code>\n    return tries.stream()<\/code>\n        .filter(Try::isSuccess)<\/code>\n        .map(Try::get)<\/code>\n        .collect(toList());<\/code>\n} else {<\/code>\n    throw new IllegalArgumentException(\"Too many invalid dates\");<\/code>\n}<\/code><\/pre>\n
Problem solved.<\/p>\n
To better understand the code, we can extract a function from it, that returns a Try<><\/code>:<\/p>\n
private static Try<Date> tryParse(SimpleDateFormat format, String s) {<\/code>\n    return Try.of(() -> format.parse(s));<\/code>\n}<\/code><\/pre>\n
This resembles the style of handling exceptions in other languages like Go and Haskell, which return the exception to their callers.<\/p>\n
By the way, if you think a bit, you could solve the problem without the Try<\/code>, by sweeping the data twice: first to count the parseable dates, and then to actually parse them. Or even a single pass using a combination of a .map<\/code> returning a null<\/code>\/Optional.empty<\/code> for errors, followed by a .filter<\/code>. That could work too, but the Try<\/code> approach might be more readable.<\/p>\n
Tip<\/strong>: Consider *vavr.Try<><\/code> when you want to collect both results and exceptions in a single pass through data.<\/p><\/blockquote>\n
By the way, if you keep thinking at the “Monad” word, here\u2019s a nice article to get you past that: Monads for Java developers<\/a><\/p>\n
Disclaimer<\/strong>: avoid streaming a large number of items in batch processing. Instead, stick with the industry default: process the data in chunks, and consider introducing Spring Batch for state-of-the-art batches.<\/p>\n
Conclusions<\/h2>\n