A TypeScript/JavaScript library providing a Result type for type-safe error handling without exceptions.
Neverthrow is a library for JavaScript and TypeScript that provides a `Result` type for type-safe error handling. It allows developers to represent operations that can succeed or fail as explicit `Ok` or `Err` values, eliminating the need for thrown exceptions. This makes error handling predictable, composable, and fully type-checked.
TypeScript and JavaScript developers building applications where robust, explicit error handling is critical, such as backend services, data processing pipelines, or any system requiring high reliability.
Developers choose Neverthrow because it brings Rust-like error handling to JavaScript/TypeScript, offering compile-time safety, fluent APIs for chaining operations, and utilities to seamlessly integrate with existing promise-based or exception-throwing code.
Type-Safe Errors for JS & TypeScript
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Encapsulates success and failure in TypeScript types, eliminating uncaught exceptions and enabling compile-time checks, as shown in the Result<T, E> generic signatures throughout the API.
Provides combinators like map, andThen, and orElse for chainable operations, allowing complex error flows without nested conditionals, similar to promises but with error awareness.
ResultAsync wraps Promise<Result> and is thenable, enabling synchronous-style error handling for asynchronous code without manual await chaining, detailed in the asyncAndThen and asyncMap methods.
Utilities like fromThrowable and fromAsyncThrowable convert exception-throwing functions into Result-returning ones, making it safe to integrate with libraries that use throw, as demonstrated in the wrapping examples.
Demands familiarity with concepts like monads and combinators, which can be a steep learning curve for developers used to imperative JavaScript, evident in methods like andThen and safeTry using generators.
For straightforward error handling, using Results can be more verbose than try/catch, as seen in the safeTry example which requires a generator function for implicit error returns.
Adds a third-party library to core error handling, with potential performance costs from object wrappers and method calls, though not explicitly benchmarked in the README.