user-expectations-6 #21
Conversation
Synchronous exception in Promise constructor always rejects even if promise is already resolved.
There was a problem hiding this comment.
Very nice, generally LGTM - left a question about adding another "what we might be able to do better".
Could you also edit it into https://github.com/nodejs/promise-use-cases/blob/master/meeting-discussion.md perhaps?
|
|
||
| Promises can only be resolved to a fulfillment or rejection, and once resolved, cannot be changed. This normally makes sense, but in this specific case of an accidental exception that occurs synchronously subsequent to the otherwise resolution (fulfillment or rejection), the user never expects the promise machinery to just suppress/hide that exception. | ||
|
|
||
| ### What can we maybe do better |
There was a problem hiding this comment.
I think it would be interesting to also suggest an asnyc_hook here - a function that will be called on all throws inside a promise constructor and report them to APMs or implement the behavior below, WDYT?
There was a problem hiding this comment.
I may not fully know what an "async_hook" is, but I shyed away from that because this use-case is specifically about synchronous behavior (both the resolution and the exception overriding it).
Having a hook to be notified of these cases is not a bad idea, but I organized this use-case under "expectations" because I think most users would tend to just expect this suggested behavior. So a hook would sorta be augmentative of that rather than an alternative.
|
added a new commit with edit to meeting-discussion README |
|
Thanks |
|
@getify I remember (while using $q service in AngularJS 1.x to create a function that returns a promise) that all the codes was executed ordinary after the resolve call (In that case the console were called. Is that related to different implementation of the AngularJS team? |
Synchronous exception in Promise constructor always rejects even if promise is already resolved.
re: #5