# Introduction

## Handle success and failure in Java 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.


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

{% hint style="success" %} `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. {% endhint %} ### 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. {% hint style="info" %} 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](https://result.leakyabstractions.com/extra/benchmarks). {% endhint %} 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()`.

{% hint style="success" %} `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. {% endhint %} ### Ready to Tap into the Power of Results? Read the guide and transform your error handling today. {% content-ref url="docs/start" %} [start](https://result.leakyabstractions.com/docs/start) {% endcontent-ref %} {% content-ref url="docs/basic" %} [basic](https://result.leakyabstractions.com/docs/basic) {% endcontent-ref %} {% content-ref url="docs/advanced" %} [advanced](https://result.leakyabstractions.com/docs/advanced) {% endcontent-ref %} Also available as an **ebook** in multiple formats. [Download your free copy now!](https://leanpub.com/result/) ### TL;DR Not a fan of reading long docs? No worries! Tune in to *Deep Dive*, a podcast generated by [NetbookLM](https://notebooklm.google.com/). In just a few minutes, you'll get the essential details and a fun intro to what this library can do for you! {% embed url="" %}