effect VS proposal-error-cause

Effect is a functional library for building and composing asynchronous, concurrent, and reactive programs in TypeScript. It focuses on providing a robust and type-safe way to manage side effects in your programs.

Just use a library that already contains this and more functional programming idioms, like fp-ts or its successor, Effect [0]. It is a little more complex to learn but much more robust that simply implementing your own Result and other types.

[0] https://www.effect.website/

effect-ts

:::note When using remote APIs, we often have the possibility to generate the types automatically from a JSON schema for REST APIs, from protobuf files for gRPC-based APIs, from a database schema, etc. You might even be using an external API through an SDK that already provides you with all types. In such cases, the creation of specialized Error classes is not mandatory. However, it might still be a good idea to do so to provide application-specific errors rather than bubbling up 3rd-party low-level errors. For such cases, the upcoming Ecma TC39 proposal for Error Cause is useful as it allows to chain errors. Polyfills exist: Pony Cause or error-cause. :::

Error Cause : .cause property on all Error types slides.

The impact and cause provides the most value when paired with the other, and that's what Error Cause enables and what Pony Cause is is a ponyfill for and provides helpers for.

Well, we have error-cause on stage-3 for the same and with which we could do something like:

Error Cause: Enhancing errors with a distinct "cause".

Error Cause