ServiceResult and Functional Result Handling

To be Reviewed By: August 28th, 2020

Authors: Patrick Johnson

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: ClassLoader Isolation

Problem

Typically Geode handles failure by exception; If an issue is encountered while executing code, an exception is thrown and propagated up until either it is caught or it crashes the system. It's too easy to miss an exception and allow it to propagate farther up than it needs to and by the time it gets to that level, it may have been wrapped by another exception and lost its context on the root cause. This isn't ideal because we obviously don't want the system to go down, but we definitely want to know when a failure occurs and what caused it. Since exception handling is messy and expensive, it would be best to avoid it when possible.

Anti-Goals

This proposal is concerned only with introducing a better way to handle failure and does not intend to...

• Add or remove any exception types from Geode.
• Remove and replace all exception throwing, catching, or handling.

Solution

The proposed solution is to take a more functional approach to error handling by introducing a Result interface. A Result will represent the result of an operation and take two type parameters, a SuccessType and a FailureType. The SuccessType will be the expected result of the operation and the FailureType will be the type to return if the operation fails. The Result interface will have methods to...

• Check if the operation succeeded or failed
• Return the success result (SuccessType) assuming the operation succeeded
• Return the error result (FailureType) assuming the operation failed

To make the Result simpler to use, there will be another interface called ServiceResult that will extend Result. ServiceResult will only take one type-parameter, SuccessType, and will use String as the FailureType to be able to return an error message. ServiceResult also adds some useful methods to allow interact with the Result using lambdas. 

There will be two concrete implementations of ServiceResult: Success and Failure. Success will carry a result of SuccessType and identity itself as successful when asked. Failure will carry a String error message and identify itself as a failure. A method that uses this new way of handling results should return a Success with the result when the operation succeeds and a Failure with a meaningful error message when something goes wrong. The caller can then check whether the operation succeeded or failed and act accordingly by retrieving the result, or handling the error as they see fit (ignore it, print the error message, exit, recover, etc.). Note that trying to get a result from Failure or trying to get an error message from Success is to allowed and will result in an exception being thrown–you should check for success or failure before attempting to access the result or error message.

ServiceResult makes it easy to indicate success or failure and pass back either a result or a useful message without throwing an exception.

Use Cases

Scenario 1: 

Expected behavior: 

Changes and Additions to Public Interfaces

Addition of Result, ServiceResult, Success, and Failure. No changes to existing public interfaces.

Performance Impact

No anticipated performance impact.

Backwards Compatibility and Upgrade Path

No backward compatibility impact.

Prior Art

An alternative would be to continue handling errors by exception.

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?