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

On this page
  • Benchmarking Result Library
  • Simple Scenarios
  • Complex Scenarios
  • Conclusion

Was this helpful?

Edit on GitHub
Export as PDF
  1. Other resources

Benchmarks

Measuring performance to find out how fast Results are

PreviousBill of MaterialsNextDemo Projects

Last updated 6 months ago

Was this helpful?

Throughout these guides, we have mentioned that throwing Java exceptions is slow. But... how slow? According to our benchmarks, throwing an exception is several orders of magnitude slower than returning a failed result.

Returning a failed Result object is significantly faster than throwing an exception.

This proves that using exceptional logic just to control normal program flow is a bad idea.

We should throw exceptions sparingly, even more so when developing performance-critical applications.

Benchmarking Result Library

Simple Scenarios

The first scenarios compare the most basic usage: a method that returns a String or fails, depending on a given int parameter:

Using Exceptions

public String usingExceptions(int number) throws SimpleException {
  if (number < 0) {
    throw new SimpleException(number);
  }
  return "ok";
}

Using Results

public Result<String, SimpleFailure> usingResults(int number) {
  if (number < 0) {
    return Results.failure(new SimpleFailure(number));
  }
  return Results.success("ok");
}

Complex Scenarios

The next scenarios do something a little bit more elaborate: a method invokes the previous method to retrieve a String; if successful, then converts it to upper case; otherwise transforms the "simple" error into a "complex" error.

Using Exceptions

public String usingExceptions(int number) throws ComplexException {
  try {
    return simple.usingExceptions(number).toUpperCase();
  } catch (SimpleException e) {
    throw new ComplexException(e);
  }
}

Using Results

public Result<String, ComplexFailure> usingResults(int number) {
  return simple.usingResults(number)
    .map(String::toUpperCase, ComplexFailure::new);
}

Conclusion

We provided insights into the Result library's performance through benchmarking. While our metrics corroborate that most codebases could benefit from using this library instead of throwing exceptions, its main goal is to help promote best practices and implement proper error handling.

To address performance concerns, benchmark your applications to gain reusable insights. These should guide your decisions on selecting frameworks and libraries.

This library comes with when using results versus when using exceptions.

📈
a set of benchmarks that compare performance