neverthrow VS boxed

Very timely, was just trying to understand how to improve error handling with typescript recently and came across neverthrow (https://github.com/supermacro/neverthrow) which looks promising…

On my team we use Rust-style Result/Option types for any unrecoverable exceptions.

https://github.com/supermacro/neverthrow

I was happy when Promise became available, but in retrospect I'd wish we would have skipped ahead and gotten Observable (e.g: https://rxjs.dev/) instead to enable more powerful functionality and composition etc.

In Typescript dealing with rejection is also painful since rejection reasons can't be guaranteed to be Error even when you always take care of that. And it can't help you guarantee that you're handling all types of errors thrown. For that purpose I'm thinking of using https://github.com/supermacro/neverthrow#readme or https://swan-io.github.io/boxed.

I highly recommend the neverthrow library for bringing Result to Typescript.

I like the Result monad from here: https://github.com/supermacro/neverthrow

What do you think of neverthrow?

I use https://github.com/supermacro/neverthrow for this

See neverthrow as an example of correctly encoding the failure into the return type of the function.

I use Neverthrow. Same idea, concurrent projects...

I was happy when Promise became available, but in retrospect I'd wish we would have skipped ahead and gotten Observable (e.g: https://rxjs.dev/) instead to enable more powerful functionality and composition etc.

In Typescript dealing with rejection is also painful since rejection reasons can't be guaranteed to be Error even when you always take care of that. And it can't help you guarantee that you're handling all types of errors thrown. For that purpose I'm thinking of using https://github.com/supermacro/neverthrow#readme or https://swan-io.github.io/boxed.

Agree that try/catch is verbose and not terribly ergonomic, but my solution has been to treat errors as values rather than exceptions, by default. It's much less painful to achieve this if you use a library with an implementation of a Result type, which I admin is a bit of a painful workaround, but worth it. I've recently been using: https://github.com/swan-io/boxed.

By far the greatest benefit is being able to sanely implement a type-safe API. To me, it is utter madness throwing custom extensions of the Error class arbitrarily deep in the call-stack, and then having a catch handler somewhere up the top hoping that each error case is matched and correctly translated to the intended http response (at least this seems to be a common alternative).