Much like Scala, you can use the Try type in Kotlin to functionally handle exceptions. This guide walks through a basic setup and introduces chaining with maps.
Scala has a Try type to functionally handle exceptions. I wrapped my head around that concept by using the excellent Neophyte’s guide to Scala by Daniel Westheide. This post will replicate that type using Kotlin.
Consider a simple function that takes two Strings, converts them to integers, and then divides them (sample based on Scaladoc of Try):
It is the caller’s responsibility to ensure that any exception that is propagated from this implementation is handled appropriately using the exception handling mechanism of Java/Kotlin:
My objective with the “Try” code will be to transform the “divide” into something which looks like this:
A caller of this variant of the “divide” function will not have an exception to handle through a try/catch block. Instead, it will get back the exception as a value, which it can introspect and act on as needed.
The “Try” type has two implementations corresponding to the “Success” path or a “Failure” path and is implemented as a sealed class the following way:
The “Success” type wraps around the successful result of an execution while the “Failure” type wraps any exception thrown from the execution.
So now, to add some meat to these, my first test is to return one of these types based on a clean and exceptional implementation, along these lines:
This can be achieved through a “companion object” in Kotlin, similar to static methods in Java. It returns either a Success type or a Failure type based on the execution of the lambda expression:
Now that a caller has a “Try” type, they can check whether it is a “Success” type or a “Failure” type using the “when” expression like before, or using “isSuccess” and “isFailure” methods, which are delegated to the sub-types like this:
In case of Failure, a default can be returned to the caller, something like this in a test:
Again implemented by delegating to the subtypes:
The biggest advantage of returning a “Try” type, however, is in chaining further operations on the type.
A “map” operation is passed a lambda expression to transform the value in some form — possibly even to a different type:
Here, a number is being doubled and then converted to a string. If the initial Try were a “Failure”, then the final value will simply return the “Failure” along the lines of this test:
Implementing “map” is fairly straightforward:
flatMap, on the other hand, takes in a lambda expression, which returns another “Try” type and flattens the result back into a “Try” type along the lines of this test:
Implementing this is simple too, along the following lines:
The “map” and “flatMap” methods are the power tools of this type, allowing chaining of complex operations together and focusing on the happy path.
Try is a powerful type, allowing a functional handling of exceptions in code. I have a strawman implementation using Kotlin available in my GitHub repo here.
