prevent passing a specific error type for .fromThrowable without providing an error mapping function
#583
Conversation
🦋 Changeset detectedLatest commit: 6736079 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| @@ -0,0 +1,5 @@ | |||
| --- | |||
| 'neverthrow': minor | |||
There was a problem hiding this comment.
This might be considered a breaking change, since users that use the function like described in the PR will get red squiggles. However, I would argue that this is a "type bug", and shouldn't be considered a valid use case
There was a problem hiding this comment.
I'd agree to consider this a bug fix
| /** | ||
| * Wraps a function with a try catch, creating a new function with the same | ||
| * arguments but returning `Ok` if successful, `Err` if the function throws | ||
| * | ||
| * @param fn function to wrap with ok on success or err on failure | ||
| * @param errorFn when an error is thrown, this will wrap the error result | ||
| */ |
There was a problem hiding this comment.
It's not the most elegant to have to maintain two versions of the documentation, however I'm not aware of any other way of doing it. Please let me know if there's a better way!
As discussed in #567 (comment), the current type signature of
fromThrowableallows users to pass a specific error value type, without providing an error mapping function that produces the provided error type:This PR tries to solve that by adding some overloads to the function, only allowing users to specify the error type when a matching error mapping function is provided.