neverthrow | Type-Safe Errors for JS & TypeScript | Reactive Programming library

There's few benefits to using something like the ResultAsync type instead of a Promise.

As can be seen from the type itself, the former option has a E generic parameter indicating the types of errors that the result may contain. This is hugely beneficial, as you can deal with each error type independently instead of catching a generic error instance. Take for example HTMLImageElement.decode; it returns a promise that might throw EncodingError, but you wouldn't know that without checking documentation.

Another benefit comes from being forced to deal with the potential error result. Javascript errors are unchecked, meaning that there is no compiler or interpreter to ensure that you always wrap await promise in a try-catch. On the other hand, when you await result, you must check whether it yielded a result (result.isOk() === true) or threw an error (result.isErr() === true). This means that every time you want to unwrap (get T from Result) a result, you must deal with the potential error cases. In theory, this results in more robust and fail-safe code.

Result does not come without its downsides though. Javascript ecosystem has adopted Promises as the standard way to return things asynchronously, so ResultAsync may not work everywhere Promise would. Also, having to deal with potential error results every time you want to unwrap a result makes code more verbose.

If you're mostly dealing with async code written within the same project and think you could benefit from more fail-safe code, it may make sense to use ResultAsync everywhere you'd use Promise.