(In reply to Tooru Fujisawa [:arai] from comment #9) > I was thinking that, using single pre-allocated unsettled promise JSObject for all failure case will make the situation more complex, > because resolving/rejecting it in one place will affect all other cases. But in that case it should never be resolved/rejected, should it? > If `JSObject`-less `dom::Promise` works for the DOM Streams case, that should be better. 👍 Hi Olli, I think I'll go ahead and make Promise::CreateInfallible that leaves `mPromiseObject` null, and adjust MaybeReject/Resolve to be no-op when it's null. What do you think?
Bug 1762233 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Tooru Fujisawa [:arai] from comment #9) > I was thinking that, using single pre-allocated unsettled promise JSObject for all failure case will make the situation more complex, > because resolving/rejecting it in one place will affect all other cases. But in that case it should never be resolved/rejected, should it? > If `JSObject`-less `dom::Promise` works for the DOM Streams case, that should be better. 👍 Hi Olli, I think I'll go ahead and make Promise::CreateInfallible that leaves `mPromiseObject` null, and adjust MaybeReject/Resolve to be no-op when it's null. What do you think? Reasoning: IMO it's more or less equivalent to have a never-settled promise behavior-wise, because Streams currently just throw when promise creation fails which will probably reach nothing when JS context is already dead.