-
Notifications
You must be signed in to change notification settings - Fork 68
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
Suggestion needed - Wrapping AsyncGenerator #115
Comments
Hi @Chuckytuh, thanks for opening this discussion. I don’t use generators personally but here is my interpretation: the Do you any other way to handle the error case ? |
Thanks @paduc for engaging on the discussion! Yes, that makes sense and was my first impression as well, sadly, this breaks the norm which means that other APIs, such as It seems to be one of those cases where we can't get both worlds to live happily. If we want our AsyncGenerators to have errors modelled into the return type (through |
If the consumer expects an exception for the normal case, then it’s totally fine to throw an exception to comply. ´Result’ are useful to have typed errors, meaning the consumer can determine which kind of error is thrown. In your case, the expected exception is not really an error but rather a signal for the consumer to stop. I don’t think it’s appropriate to wrap that exception in a ´Result’. If your generator does have other types of errors (ex: connection lost), then you can use the ´Result’ type to handle those. |
Going to leave this issue open as I don't have much experience with Generators. Hopefully others in the community can chime in and provide more info! |
I'm adding a bounty to this if it ever gets resolved; $100 USD |
That case would be better solved by streams (see e.g. RxJS solutions). What you roughly do here is: maintain a stream reading iterables that you flatten (with mapping) into the stream. You could convert to async iteration from the streaming with some small effort (see e.g. this implementation on StackOverflow). Iʼd second @paduc here (providing him with bounty!) and avoid |
Sorry for opening an issue with what is basically a question/ feedback for API ergonomics...
Has any of you stumbled upon a situation where you'd want to wrap an AsynGenerator in a Result somehow where the ultimate goal is to typify the possible errors and effectively not have it throwing exceptions?
Let's say that the AsyncGenerator is wrapping a REST API Call and yielding results over time:
One way I see it, is to have the generator return Results and as soon as an exception is thrown/promise rejection occurs, yield the error. This breaks the iteration as soon as the error occurs however, the side effect is that now the consumer has to unwrap each received value from the result and this breaks the norms of common generators.
The text was updated successfully, but these errors were encountered: