Skip to content

Allow propagating errors from Asyncified imports back to C++ #11434

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

Open
RReverser opened this issue Jun 17, 2020 · 3 comments
Open

Allow propagating errors from Asyncified imports back to C++ #11434

RReverser opened this issue Jun 17, 2020 · 3 comments
Labels

Comments

@RReverser
Copy link
Collaborator

Right now, from what I understand, there is no way to wake up the C++ side with an error instead of a successful value. This makes errors in Asyncified functions behave differently than in regular imports in that, upon an async error, the C++ code can never be resumed, and such error has no chance of getting handled, and instead only ends up being printed to the Console.

This is not very important for wakeUp based handler, but in promises rejections are fairly common, and would be good to propagate those somehow back to C++.

I'd imagine following Promise's design here might be easy enough; basically, they have a resolve and reject callbacks, and are guaranteed that whatever is called first, wins, and no further resolution/rejection occurs.

As far as I can tell, wakeUp is a direct analogy for the resolve callback, so I'd imagine we could simply extend API to accept a reject callback as well, store it on the state, and on C++ side it would call throw instead of continuing execution.

@kripken
Copy link
Member

kripken commented Jun 18, 2020

Sounds reasonable to me. Is there a risk of breaking existing users by adding it?

@RReverser
Copy link
Collaborator Author

There is a potential risk that silently swallowed errors will suddenly be thrown on C++ side, but I suppose

  1. It's a better state of things anyway as it only reveals already existing problems and makes them easier to catch.
  2. Worst case, that error should get propagated back from C++ to JS again and still printed to console, but with more informative stacktrace.

So I don't see how this would break any valid real-world code.

@stale
Copy link

stale bot commented Jun 18, 2021

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Jun 18, 2021
@stale stale bot removed the wontfix label Jul 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants