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

Throws and rejections #7

Closed
Ginden opened this issue Mar 29, 2022 · 1 comment
Closed

Throws and rejections #7

Ginden opened this issue Mar 29, 2022 · 1 comment
Labels
duplicate This issue or pull request already exists

Comments

@Ginden
Copy link

Ginden commented Mar 29, 2022

Let's consider following case:

function fooRaw() {
    throw new Error(`let's see stack trace');
}
const foo = fooRaw.once();

function a() {
   foo();
}


function b() {
   foo();
}

a();
b(); // What is stack trace here? Is thrown object the same?

Most of implementations don't store thrown errors, but it's important design decision.

Another thing to consider are async functions - how are rejections handled? It would be surprising for sync functions not to save call result, but save it for rejected promises.

@js-choi js-choi mentioned this issue Mar 30, 2022
@js-choi js-choi added the duplicate This issue or pull request already exists label Mar 30, 2022
@js-choi
Copy link
Collaborator

js-choi commented Mar 30, 2022

Thanks for raising this issue. It seems to encompass two topics: how to handle sync errors thrown by the first call and whether to handle async functions in a special way.

We’re already discussing the first topic (sync errors from the first call), in #2. In particular, see the plenary findings in #2 (comment) – the plenary was slightly in favor of returning undefined every time, as well as throwing any sync error from the first call only once—and never again on subsequent calls.

We could branch that out into this dedicated issue, I suppose. But sync error handling is closely coupled to the decision we make for #2, which is currently inclined toward returning undefined every time, so promise handling is moot anyway. (I will edit #2’s original post to mention sync error handling.)

The other topic is about async functions. If we go with once functions returning undefined every time, then we might want to also have onceAsync functions that each return the same promise from every call—otherwise it is impossible to know whether onceAsync functions have thrown errors. I think that may be out of scope of this proposal, but I can create a new issue for it anyway.

I will close this issue as a duplicate of #2 and #7. Let me know if you feel this isn’t yet resolved or adequately handled by #2 or #7.

@js-choi js-choi closed this as completed Mar 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants