-
Notifications
You must be signed in to change notification settings - Fork 2
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
mightFail.any's error type is inaccurate #20
Comments
does your last pr fix all the issues, or are you still manually casting that error type? |
No this is a different issue. I was making a function that wrapped two promises in an mightFail.any and the typing were messed up. It gave me a headache that's why I'm still procrastinating on fixing it |
I will get back to this, I promise |
@meech-ward I've added an API for passing custom Errors to the Either type to fix the issue of having to cast And, about the issue of having to cast the const either: Either<T> = (await mightFail.any([ I don't think it's something we can fix because the There are other changes that are irrelevant to this issue that are mentioned in the PR description itself. |
PR done, hopefully it fixes all this? |
Yeah, I think it should be fine. The main issue was the Error casting that was annoying. |
I had to manually cast the error type to AggregateError here:
And regarding the last comment, I would just get rid of the
NotUndefined
thing because it's creating additional complexity just for the sake of "semantics". It removes the flexibility of the users while enforcing a best practice in a flawed language called JavaScript.The text was updated successfully, but these errors were encountered: