Skip to content
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

Closed
iliaamiri opened this issue Nov 1, 2024 · 6 comments
Closed

mightFail.any's error type is inaccurate #20

iliaamiri opened this issue Nov 1, 2024 · 6 comments

Comments

@iliaamiri
Copy link
Member

iliaamiri commented Nov 1, 2024

I had to manually cast the error type to AggregateError here:

async function performSomethingWhileTryCheckForOtherStuff<T>(callback: () => Promise<Either<T>>): Promise<Either<T>> {
  const either: Either<T> = (await mightFail.any([
    callback(),
    new Promise((_, reject) => {
      return checkForNewRecordsAndMarkAsUpdated().finally(() => reject());
    }),
  ])) as Either<T>;

  if (either.error) {
    const aggregateError = either.error as AggregateError; // I shouldn't have to do this myself
    return Fail(aggregateError.errors[0]);
  }

  return Might(either.result as any); // Also, this is already addressed and I am encountering it again. https://github.com/might-fail/ts/pull/19#issuecomment-2451114060 
}

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.

@iliaamiri iliaamiri changed the title mightFail.any return types are not useful mightFail.any's error type is inaccurate Nov 1, 2024
@meech-ward
Copy link
Collaborator

does your last pr fix all the issues, or are you still manually casting that error type?

@iliaamiri
Copy link
Member Author

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

@iliaamiri
Copy link
Member Author

I will get back to this, I promise

@iliaamiri
Copy link
Member Author

iliaamiri commented Dec 7, 2024

#22

@meech-ward I've added an API for passing custom Errors to the Either type to fix the issue of having to cast AggregateError to the error of mightFail.any. It seems like a core addition since it added a generic type to the Either types.

And, about the issue of having to cast the either variable in the second line:

 const either: Either<T> = (await mightFail.any([

I don't think it's something we can fix because the callback() causes extra complexity as it also returns Either. But, I'll think about it some more and maybe figure out something. But before that, I kind of wanted the current PR to be merged as I didn't want to change too much in one PR.

There are other changes that are irrelevant to this issue that are mentioned in the PR description itself.

@meech-ward
Copy link
Collaborator

PR done, hopefully it fixes all this?

@iliaamiri
Copy link
Member Author

Yeah, I think it should be fine. The main issue was the Error casting that was annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants