Page History

...

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 crash Geode or swallow it without reporting an error at all. Exceptions may also be caught, wrapped, and rethrown multiple times on their way up the stack so, by the time they reach the surface, all context on the root cause of failure is lost.  This 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 dangerous and messy and as well as expensive, it would be is best to avoid it when possible.

...

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

Solution

Fortunately, there are other ways to handle failure besides exceptions–just return a normal type that may contain either a result or an error. This isn't a new concept, errors are handled this way in Go and even in parts of Geode. That's right, this idea is already being used by geode-protobuf and in the work related to the ClassLoader Isolation RFC. The proposed solution is to take a use this more functional approach to error handling in more places throughout Geode by introducing a new generic 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 (isSuccessful() and isFailure())
• 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 interaction 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. While throwing an exception here isn't ideal, it's necessary for some circumstances.

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:

...

 An operation completes successfully.

Expected behavior: A Success object is returned. Calling isSuccess() on the Success returns true and calling isFailure() returns false. The Success contains the result of the operation (SuccessType).

Scenario 2: An operation encountered an error.

Expected behavior: A Failure object is returned. Calling isFailure() on the Failure returns true and calling isSuccess() returns false. The Failure contains an error message describing the error.

...

Changes and Additions to Public Interfaces

...

Performance Impact

No anticipated performance impact.

...