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
When I cancel a chain of promises, how do error handlers work?
We'll assume automatic propagation of the cancellation to parent promises, regardless how it's implemented. Let's have a
var cancellable = parentCancellable.then(doSomething, handleSomething);
Now when I call cancellable.cancel() (or whatever we use to signal cancellation), then parentCancellable will be rejected with a CancellationError. But what happens to cancellable? Is it supposed to be rejected with the same error? Or does its fate depend on the result of handleSomething() (which is required to be called by the A+spec)? Both options have their problems:
reject it:
what happens to all the error handlers in the chain? All of them are executed, but their results are ignored.
re-thrown (mutated?) exceptions, or wrapped (new) exceptions, are ignored instead of bubbling up the chain (all the result promises are already rejected). This creates a lot of unhandled rejections.
fulfillment values are created, but cannot be used. Returning a child promise from the handler might even leave dangling asynchronous jobs hang around. Do they need to be instantly cancelled as well? Still, even creating them is unnecessary overhead.
Sure, no handler that cannot deal with a CancellationError should be executed at all, but my hunch says the only the fewest catch clauses involve typechecking.
let errors bubble as usual:
Can lead to very odd behaviour. Do I really need to call .cancel() multiple (indefinite?) times to be sure that a chain of promise actions has been completely aborted?
I would expect a (pending) promise (that I "own", of which I know that there are no other listeners waiting for) to never fulfill after I have called .cancel() on it. Is this the use case that we need .fork() for, and such a method needs to give this guarantee, not (.then(null)).cancel() itself? Draft A #2 Draft A seems to work around this by introducing the cancelled state, which locks the promise in a pending-like state that guarantees that no handlers will ever be called. However, such will jeopardize proper working of .finally() and similar, and make .oncancelled handlers or cancel progress events necessary.
The text was updated successfully, but these errors were encountered:
bergus
changed the title
Cancel the every promise in the chain, or only the deepest cancellable ancestor?
Cancel every promise in the chain, or only the deepest cancellable ancestor?
Jul 22, 2014
When I cancel a chain of promises, how do error handlers work?
We'll assume automatic propagation of the cancellation to parent promises, regardless how it's implemented. Let's have a
Now when I call
cancellable.cancel()
(or whatever we use to signal cancellation), thenparentCancellable
will be rejected with aCancellationError
. But what happens tocancellable
? Is it supposed to be rejected with the same error? Or does its fate depend on the result ofhandleSomething()
(which is required to be called by the A+spec)? Both options have their problems:reject it:
Sure, no handler that cannot deal with a
CancellationError
should be executed at all, but my hunch says the only the fewestcatch
clauses involve typechecking.let errors bubble as usual:
.cancel()
multiple (indefinite?) times to be sure that a chain of promise actions has been completely aborted?.cancel()
on it. Is this the use case that we need.fork()
for, and such a method needs to give this guarantee, not (.then(null)
).cancel()
itself?Draft A #2 Draft A seems to work around this by introducing the
cancelled
state, which locks the promise in a pending-like state that guarantees that no handlers will ever be called. However, such will jeopardize proper working of.finally()
and similar, and make.oncancelled
handlers orcancel
progress events necessary.The text was updated successfully, but these errors were encountered: