Checked exceptions & Java 8
Defining custom exceptions (both checked and unchecked) is a common approach to handling errors in Java applications. It usually leads to creating a new class for every different type of error, marking methods with throws keyword or wrapping code with try-catch blocks. This can lead to the code which is hard to read since every block adds another level of complexity.
Lambdas in Java 8 started the boom for functional approach in writing the code. Developers are now more familiar with these concepts and seeing -> in the code has became daily thing. Unfortunately, functional programming doesn't play well with Java exceptions - especially checked ones.
The main drawback is that method cannot be matched to functional interfaces from java.util.function if it throws a checked exception. This makes developers create custom functional interfaces with throws clauses, duplicating the code from JDK or write nasty try-catch block in lambdas. You can use RuntimeException type to model your custom exceptions but then the information about possible failure is lost and handling it is not required by compiler anymore.
Result monad
Solution suggested by myself uses custom Result class which is similar to the Optional monad. Optional is a box for objects that may exist - Optional keeps a reference to that object - or not - Optional keeps null. Result on the other hand can be a Success - code was executed correctly and the value is ready - or Failure - some error occurred. Here is the fragment of Result interface:
1
2
3
4
5
6
7
8
9
10
11
12
| public interface Result<T> {
boolean isSuccess();
T getResult();
ErrorType getError();
String getOptionalErrorMessage();
...
}
|
Success implementation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| public final class Success<T> implements Result<T> {
private final T result;
...
public boolean isSuccess() {
return true;
}
@Override
public ErrorType getError() {
throw new NoSuchElementException("There is no error in Success");
}
@Override
public String getOptionalErrorMessage() {
throw new NoSuchElementException("There is no optional error message in Success");
}
@Override
public T getResult() {
return result;
}
}
|
Failure implementation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| public final class Failure<T> implements Result<T> {
private final ErrorType error;
private final String optionalErrorMessage;
...
@Override
public boolean isSuccess() {
return false;
}
@Override
public ErrorType getError() {
return error;
}
@Override
public String getOptionalErrorMessage() {
return optionalErrorMessage;
}
@Override
public T getResult() {
throw new NoSuchElementException("There is no result is Failure");
}
}
|
ErrorType is a type which represents predefined error condition. It sometimes comes with the optional error message. We could actually store Exception type instead of ErrorType but custom class gives more flexibility. Similarly to Optional, Result has get* methods which allow to access the internal state. They shouldn't be used without isSuccess method because they could result in throwing NoSuchElementException. They are helpful for unit tests, when you just want the value inside to assert on it.
Nothing fun so far. Let's have a look at the rest of the Result interface:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| public interface Result<T> {
...
default <R> Result<R> map(Function<? super T, ? extends R> mapper) {
return isSuccess() ?
Success.of(mapper.apply(getResult())):
(Failure<R>) this;
}
default <R> Result<R> flatMap(Function<? super T, Result<R>> mapper) {
return isSuccess() ?
mapper.apply(getResult())
(Failure<R>) this;
}
default <R> R fold(Function<? super T, ? extends R> successFunction, Function<Failure<R>, ? extends R> failureFunction) {
return isSuccess() ?
successFunction.apply(getResult()) :
failureFunction.apply((Failure<R>) this);
}
}
|
More about these methods later. Now, let's put it to use. When using libraries that declare checked exceptions, we would like to map every successful method call to Success and every cached exception to Failure. So the code like this:
1
2
3
4
5
6
7
| public String getNameById(int id) throws DatabaseAccessException {
try {
return dbClient.getNameById(id);
} catch (DatabaseAccessException e) {
throw new CustomException(e);
}
}
|
will become:
1
2
3
4
5
6
7
| public Result<String> getNameById(int id) {
try {
return Success.of(dbClient.getNameById(id));
} catch (DatabaseAccessException e) {
return Failure.of(PREDEFINED_DB_ERROR, e.getMessage());
}
}
|
(There are existing solutions like scala's/vavyr's Try, which skip the try - catch block totally and operate on Exception type. I prefer to use my custom ErrorType but you are free to use different approach. By using ErrorType you will also save some time by not wrapping the exception in custom one, which uses costly Throwable.fillInStackTrace - article.)
Result usage in business code
Now suppose we would like to use it in our business code. Here is the interface from persistence layer interface modeled with the usage of Result:
1
2
3
4
5
6
7
| public interface DbConnector {
Result<String> getNameById(int id);
Result<Integer> getAgeByName(String name);
}
|
Suppose we want to use it in our business code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| class BusinessClass {
private final DbConnector dbConnector;
...
public Result<Boolean> isAdult(int userId) {
return dbConnector.getNameById(userId)
.flatMap(userName -> dbConnector.getAgeByName(userName)) // or simpler: .flatMap(dbConnector::getAgeByName)
.map(userAge -> userAge >= 18);
}
}
|
Method isAdult pulls the user's name from database and then uses it to fetch the age of that person (weird API but that's just an example :)). Finally it maps the age of that person to the boolean which indicates whether this person is an adult or not. What is important here, is that there are two calls which can result in Failure, sequenced using flatMap. The final invocation of map cannot fail because the predicate 'userAge >=18' will not be applied if the result from flatMap is Failure. The same way, function passed to flatMap will not be applied if getNameById returns a Failure - this Failure will be passed down the invocation stream to the caller of isAduld. Both map and flatMap will only invoke the passed method, if the Result is Success. This way we can model the business flow, but what if we want to unwrap the value inside, for example to return it to the client?:
1
2
3
4
| Result<Boolean> isAduld = isAduld(userId);
String response = isAduld.fold(
userIsAdult -> "adult: " + userIsAdult,
failure -> "error occurred: " + failure.getError().show());
|
Fold will reduce the Result to the single value using provided functions - first if it's Success or second if it's Failure. Remember not to use just get method instead.
Summing up
map - applies function to value inside if it's Success, otherwise does nothing
flatMap - applies function which returns Result to value inside if it's Success, otherwise does nothing
fold - applies success function to value inside if it's Success, otherwise applies failure function to the ErrorType - reduces Result to singe value
The flow can also be started from:
ReplyDeleteFunction.identity().andThen(this::mapRequest) but I find it harder to read.