You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if WebIDL provided a means to mark a method as async, like:
interfaceFoo {
asyncreturnValuewhatever();
}
I was reading the Web Payments spec and noticed that they are using exceptions and promises incorrectly (they try to throw exceptions before they return the promise). Something like the above would prevent such issues by implicitly returning the promise. Any thrown exceptions in the method's prose will then just be converted to rejections by the promise machinery.
Furthermore, such methods could then use "await" semantics if they need to wait for other methods or even internal "promises", etc.
So, like:
When foo() is called:
If some condition, throw a WhatEvesError.
If [[slot]] was not set, throw NotAllowedError.
Let x be there result of awaiting thing that happens in another thread (where "thing" runs in parallel).
return x.
And 4. nicely resolves the promise. Or some such.
The text was updated successfully, but these errors were encountered:
This is already provided by Web IDL. Returning a promise type implicitly transforms any throws to rejections and returns to fulfillments: https://heycam.github.io/webidl/#dfn-create-operation-function step 2. So instead of async returnValue just do Promise<returnValue>. I think it's bad practice to be implicit in this way though.
I think the awaiting construct you describe is not good. It's mixing up two things: in parallel, and promises. You shouldn't be able to await non-promises. If you want to await promises, use https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled; if you want to wait until things run in parallel, just "Wait, in parallel".
It would be nice if WebIDL provided a means to mark a method as async, like:
I was reading the Web Payments spec and noticed that they are using exceptions and promises incorrectly (they try to throw exceptions before they return the promise). Something like the above would prevent such issues by implicitly returning the promise. Any thrown exceptions in the method's prose will then just be converted to rejections by the promise machinery.
Furthermore, such methods could then use "await" semantics if they need to wait for other methods or even internal "promises", etc.
So, like:
And 4. nicely resolves the promise. Or some such.
The text was updated successfully, but these errors were encountered: