LogoLogo
GitHubFree book
  • 🏠Introduction
  • Using the Library
    • ðŸŒąGetting Started
      • Adding Result to Your Build
      • Creating Results
    • ðŸŠīBasic Usage
      • Checking Success or Failure
      • Unwrapping Values
      • Conditional Actions
    • 🚀Advanced Usage
      • Screening Results
      • Transforming Results
    • 🏁Recap
  • Add-ons
    • ðŸ’ĪLazy Results
    • ðŸ—ĢïļFluent Assertions
    • 📜Jackson Module
    • 🧑‍🚀Micronaut Serialization
  • Other resources
    • ðŸ“ĶBill of Materials
    • 📈Benchmarks
    • ðŸĪ–Demo Projects
      • Spring Boot Demo Project
      • Micronaut Demo Project
    • ⚖ïļLicense
Powered by GitBook
LogoLogo

Source Code

  • GitHub
  • License

Quality

  • SonarCloud
  • Benchmarks

Documentation

  • Free book
  • Javadoc

Releases

  • Maven Central
  • Bill of Materials

Copyright 2024 Guillermo Calvo

Last updated 6 months ago

Was this helpful?

A library to handle success and failure without exceptions

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

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.

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

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

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().

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.

Ready to Tap into the Power of Results?

Read the guide and transform your error handling today.

TL;DR

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 .

Also available as an ebook in multiple formats.

Not a fan of reading long docs? No worries! Tune in to Deep Dive, a podcast generated by . In just a few minutes, you'll get the essential details and a fun intro to what this library can do for you!

run faster
ðŸŒąGetting Started
ðŸŠīBasic Usage
🚀Advanced Usage
Download your free copy now!
NetbookLM

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

Using Exceptions
Using Results
Embracing Results