Package com.leakyabstractions.result.api

package com.leakyabstractions.result.api
A Java library to handle success and failure without exceptions

Result Library

Result Library for Java

Wave goodbye to slow exceptions and embrace clean, efficient error handling by encapsulating operations that may succeed or fail in a type-safe way.

  • Boost Performance: Avoid exception overhead and benefit from faster operations.
  • Simple API: Leverage a familiar interface for a smooth learning curve.
  • Streamlined Error Handling: Handle failure explicitly to simplify error propagation.
  • Safe Execution: Ensure safer and more predictable operation outcomes.
  • Enhanced Readability: Reduce complexity to make your code easier to understand.
  • Functional Style: Embrace elegant, functional programming paradigms.
  • Lightweight: Keep your project slim with no extra dependencies.
  • Open Source: Enjoy transparent, permissive Apache 2 licensing.
  • Pure Java: Seamless compatibility from JDK8 to the latest versions.

Result objects represent the outcome of an operation, removing the need to check for null. Operations that succeed produce results encapsulating a success value; operations that fail produce results with a failure value. Success and failure can be represented by whatever types make the most sense for each operation.

Results in a Nutshell

In Java, methods that can fail typically do so by throwing exceptions. Then, exception-throwing methods are called from inside a try block to handle errors in a separate catch block. 

  
 int getServerUptime() {
     int hours;
     try {
         Server server = connect();
         server.refresh();
         hours = server.getUptime();
     } catch (ConnectionException exception) {
         logger.error(exception.getMessage());
         hours = -1;
     }
     return hours;
 }

This approach is lengthy, and that's not the only problem — it's also very slow.

Conventional wisdom says exceptional logic shouldn't be used for normal program flow. Results make us deal with expected error situations explicitly to enforce good practices and make our programs run faster.

Let's now look at how the above code could be refactored if connect() returned a Result object instead of throwing an exception. 

  
 int getServerUptime() {
     final Result<Server, String> result = connect();
     result.ifSuccess(Server::refresh);
     result.ifFailure(logger::error);
     return result.mapSuccess(Server::getUptime).orElse(-1);
 }

In the example above, we used only 4 lines of code to replace the 10 that worked for the first one. But we can effortlessly make it shorter by chaining methods. In fact, since we were returning -1 just to signal that the underlying operation failed, we are better off returning a Result object upstream. This will allow us to compose operations on top of getServerUptime() just like we did with connect(). 

  
 int getServerUptime() {
     return connect().ifSuccessOrElse(Server::refresh, logger::error)
         .mapSuccess(Server::getUptime);
 }

Result objects are immutable, providing thread safety without the need for synchronization. This makes them ideal for multi-threaded applications, ensuring predictability and eliminating side effects.

Author:
Guillermo Calvo
See Also:
  • Interfaces
    Class
    Description
    Result<S,F>
    Encapsulates a single non-null value, representing the outcome of an operation that can either succeed or fail.