{"id":408,"date":"2014-03-22T15:38:15","date_gmt":"2014-03-22T14:38:15","guid":{"rendered":"http:\/\/benjiweber.co.uk\/blog\/?p=408"},"modified":"2014-04-28T14:07:44","modified_gmt":"2014-04-28T13:07:44","slug":"checked-exceptions-and-streams","status":"publish","type":"post","link":"https:\/\/benjiweber.co.uk\/blog\/2014\/03\/22\/checked-exceptions-and-streams\/","title":{"rendered":"Checked Exceptions and Streams"},"content":{"rendered":"

There are different viewpoints on how to use exceptions effectively in Java. Some people like checked exceptions, some argue they are a failed experiment and prefer exclusive use of unchecked exceptions. Others eschew exceptions entirely in favour of passing and returning types like Optional<\/a> or Maybe.<\/p>\n

Whatever your view, you are likely to need to interact with libraries written by people with a different usage of Exceptions. This often leads to ugly code to translate failure conditions into your preferred approach. <\/p>\n

This is likely to become more of a pain with Java 8, where the Streams api<\/a> doesn’t play very nicely with methods that throw exceptions.<\/p>\n

Fortunately, Java 8 also helps us translate between styles of exception usage more easily.<\/p>\n

Using Streams with Exceptions<\/h3>\n

Using the streams api can become painful when you wish to use methods that throw exceptions as maps or filters.<\/p>\n

Take this example. What happens if Example.duplicatesShortStrings throws a checked exception? It will fail to compile. <\/p>\n

The map method on the stream interface expects a Function that takes an argument and returns a value without any exceptions in its method signature. <\/p>\n

If map did accept functions that can throw exceptions then the whole chain of transformations would fail if that exception were thrown on any given element. In this example the string “booooo” is too long and will cause an exception, which means we wouldn’t get any results at all.<\/p>\n

\r\nasList(\"foo\", \"bar\", \"baz\", \"booooo\")\r\n    .stream()\r\n    .map(Example::duplicatesShortStrings) \/\/ This will fail to compile \r\n    .collect(Collectors.toList());\r\n    \r\n...\r\n\r\nString duplicatesShortStrings(String input) throws InputTooLongException {\r\n    if (input.length() > 3) throw new InputTooLongException();\r\n<\/pre>\n
How can we handle this kind of scenario better? In functional languages you might return either the result or an error from a function rather than having exceptions. The method from the example above might look more like.<\/p>\n
\r\nResult duplicatesShortStrings(String input)\r\n<\/pre>\n
That’s all very well, and easier to work with, but we are likely to be consuming lots of existing code using exceptions which we are not able to re-write. <\/p>\n
You’ll also notice that there both of these are basically equivalent<\/p>\n
\r\nResult duplicatesShortStrings(String input)\r\nString duplicatesShortStrings(String input) throws InputTooLong\r\n<\/pre>\n
What if we provide a way to translate both ways between these two styles. Then we could use streams without problems. It’s mostly possible to do this. Unfortunately, we can’t record all the possible failure conditions with generics due to lack of varargs for generic type parameters. We can, however, achieve the following.<\/p>\n
\r\nList result =\r\n    asList(\"foo\", \"bar\", \"baz\", \"boooo\")\r\n        .stream()\r\n        .map(Result.wrapReturn(Example::duplicatesShortStrings))\r\n        .map(Result.wrap(s -> s.toUpperCase()))\r\n        .filter(Result::success)\r\n        .map(Result::unwrap)\r\n        .collect(Collectors.toList());\r\n\r\nassertEquals(asList(\"FOOFOO\",\"BARBAR\",\"BAZBAZ\"), result);\r\n<\/pre>\n
Here we convert our method that throws an exception into a function that returns a Result type that encodes whether it is a success or failure and the type of failure. We can then continue to chain operations using the streams api, but as the stream is now a Stream<Result<String>> rather than a Stream<String> we need to wrap any functions that normally operate on Strings to operate on a Result<String> instead.<\/p>\n
After we’ve finished we can filter out items that did not result in an error. We also have the option of handling the errors if we wished, e.g. to provide a default value. <\/p>\n
Here we substitute the default “OhNoes” value for any entries in the stream for which a stream operation has resulted in an InputTooLongException.<\/p>\n
\r\nString result = asList(\"foo\", \"bar\", \"baz\", \"boooo\")\r\n    .stream()\r\n    .map(Result.wrapReturn(Example::duplicatesShortStrings))\r\n    .map(\r\n        Result.onSuccess((String s) -> s.toUpperCase())\r\n              .on(InputTooLongException.class, s -> \"OhNoes\")\r\n              .mapper()\r\n    )\r\n    .filter(Result::success)\r\n    .map(Result::unwrap)\r\n    .collect(Collectors.toList());\r\n\r\nassertEquals(asList(\"FOOFOO\",\"BARBAR\",\"BAZBAZ\", \"OhNoes\"), result);\r\n<\/pre>\n
To implement this we need a Result type that wraps our actual result, with two implementations – Success and Failure. Success taking a value and Failure taking an Exception<\/p>\n
\r\npublic interface Result { ... }\r\nclass Success implements Result { ... }\r\nclass Failure implements Result { ... }\r\n<\/pre>\n
We then just need to provide a helper function that transforms a method that throws an Exception into a function that returns a Result.<\/p>\n
\r\npublic static  \r\n    Function> wrapReturn(ExceptionalFunction f) {\r\n        return t -> {\r\n            try {\r\n                return new Success(f.apply(t));\r\n            } catch (Exception e) {\r\n                return new Failure(e);\r\n            }\r\n        };\r\n    }\r\n<\/pre>\n
and a function that transforms a function that operates on unwrapped types and changes it to operate on wrapped types (for the middle of the stream)<\/p>\n
\r\npublic static  Function,Result> wrap(Function f) {\r\n    return t -> {\r\n        try {\r\n            return t.map(f);\r\n        } catch (Exception e) {\r\n            return new Failure(e);\r\n        }\r\n    };\r\n}\r\n<\/pre>\n
Exception Handling Patterns<\/h3>\n
There are also a couple of very common exception handling patterns which we can make more concise. <\/p>\n
Everything unchecked<\/h4>\n
This approach involves wrapping all checked exceptions in runtime exceptions. This can be useful in the case where we don’t have a good way to handle the checked exceptions thrown by code we are calling, nor is it important for anything higher up the callstack to handle them. It is also useful if you don’t wish to use checked exceptions at all.<\/p>\n
Normally this would look something like<\/p>\n
\r\ntry {\r\n    String foo = Example.methodThatThrowsCheckedException(THROW);\r\n} catch (ACheckedExceptionIDontHaveAGoodWayToDealWith e) {\r\n    throw new RuntimeException(e);\r\n}\r\n<\/pre>\n
Now we can pull that out to a method that accepts a function and have something likely<\/p>\n
\r\n@Test(expected = RuntimeException.class)\r\npublic void checked_to_unchecked_should_wrap_in_runtime_exception() {\r\n    String foo = unchecked(() -> Example.methodThatThrowsCheckedException(THROW));\r\n}\r\n<\/pre>\n
where unchecked looks something like the following (similar implementation for void methods)<\/p>\n
\r\npublic interface ExceptionalSupplier {\r\n    T supply() throws Exception;\r\n}\r\n\r\npublic static  T unchecked(ExceptionalSupplier supplier) {\r\n    try {\r\n        return supplier.supply();\r\n    } catch (Error | RuntimeException rex) {\r\n        throw rex;\r\n    } catch (Exception e) {\r\n        throw new RuntimeException(e);\r\n    }\r\n}\r\n<\/pre>\n
Wrapping in domain specific exception<\/h4>\n
Another common pattern is catching all exceptions that may occur at a lower layer in the application and wrapping them in a more meaningful exception to consumers of your code.<\/p>\n
This used to look like this<\/p>\n
\r\ntry {\r\n    return Example.methodThatThrowsCheckedException(THROW);\r\n} catch (ACheckedExceptionIDontHaveAGoodWayToDealWith e) {\r\n    throw new Wrapped(e);\r\n}\r\n<\/pre>\n
Again we can do the same and provide something like this, where we provide a reference to the constructor of the exception that we want to wrap exceptions in. Our wrapChecked method can now construct and throw the Wrapped exception.<\/p>\n
\r\n@Test(expected = Wrapped.class)\r\npublic void wrapping_checked() throws Wrapped {\r\n    wrappingChecked(() -> Example.methodThatThrowsCheckedException(THROW)).in(Wrapped::new);\r\n}\r\n<\/pre>\n
Implementation<\/a> and examples<\/a> are on github as usual<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
There are different viewpoints on how to use exceptions effectively in Java. Some people like checked exceptions, some argue they are a failed experiment and prefer exclusive use of unchecked exceptions. Others eschew exceptions entirely in favour of passing and returning types like Optional or Maybe. Whatever your view, you are likely to need to…  Read more »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8],"tags":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n