-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why is there no ResultAsync.fromThrowable
?
#488
Comments
An implementation might look like this, which would "hoist" any synchronous errors into the async context. export const fromThrowable = <Fn extends (...args: readonly any[]) => Promise<any>, E>(
fn: Fn,
errorFn: (err: unknown) => E,
): ((...args: Parameters<Fn>) => ResultAsync<ReturnType<Fn> extends Promise<infer R> ? R : never, E>) => {
return (...args) => {
try {
return ResultAsync.fromPromise(fn(...args), errorFn)
} catch (error) {
return ResultAsync.fromPromise(Promise.reject(error), errorFn)
}
}
} |
@ehaynes99 Thanks for this ! I think this proposal merits a PR ! Could you do it ? |
Better late than never. I wasn't using this library for a while, but I added a PR for this. |
Just published now under https://github.com/supermacro/neverthrow/releases/tag/v6.2.0 |
Broken build on npm. There is no dist directory. |
Fixed in v6.2.1 .. sorry about that! |
Result.fromThrowable
takes a function as an argument, and returns a new function that returns aResult
. There is no corollary forResultAsync
, which really diminishes the utility of the library. There have been a lot of issues in here mentioning how people want to have anasync
function that returns aResultAsync
. This is just fundamentally wrong. It defeats the entire purpose of using a library like this, because the whole point is that the errors are moved from thrown, untyped values into the return type of the function.For example:
To use such a function, you would have to handle the potential error in the result, but you would also still need to wrap it in a try/catch
fromPromise
does not provide sufficient type safety, because it's possible to have synchronous error thrown while creating said promise:For
ResultAsync
to actually provide safety, it's rather critical IMO to be able to convert an arbitrary function that returns aPromise
to a wrapper enclosed withResultAsync
that is able to handle both types of errors, not just the rejectedPromise
The text was updated successfully, but these errors were encountered: