const {token, canel} = CancelToken.source();
const promise = …(token); // some promise that has the token associated
const a = promise.trifurcate(…, …, r => { throw new Error(); });
const b = promise.finally(() => { throw new Error(); });
const c = token.subscribe(r => { throw new Error(); });
const d = token.subscribeOrCall(r => { throw new Error(); }, …);
const res = cancel();
These exceptions are typically unwanted, so we definitely want them reported if no one handles them.
All of the above calls do produce a promise that is indeed rejected when the respective handler throws:
a is the promise
finally (in the current proposal) produces an internal promise that is always resolved with the handler result (and rejected here), b is essentially internal.then(() => promise, null, token) so it is cancelled here before it could be rejected (only if promise has an associated token).
c is the promise`
d is a function, but subscribeOrCall produces an internal promise that is always resolved with the handler result.
So there's always a promise that is getting rejected and could be tracked.
However, in the case A the promise is typically part of some chain, and it is possible if not quite likely that they have a cancelled rejection handler attached to them that prevents tracking (see #5).
In the case B, attaching handlers to b doesn't work as it is cancelled. The internal promise is not accessible but does have a cancelled handler attached to it - #5 again.
In the case C, the promise is surfaced but usually doesn't get any handlers attached.
In the case D, the promise is absolutely not accessible.
Handling these rejections explicitly is only possible in the cases A and C.
The current proposal presents the idea that all these rejected promises are returned by the cancel() call in an array to the canceller: res=[a, internalB, c, internalD]. The canceller (i.e. the actor that requests the cancellation) is thereby enabled to handle exceptions that happened during the cancellation. It also receives normal return values from the cancellation handlers.
Does this make sense? Or is this absolutely insane? Are there any problems with leaking information? Is this useful at all?
If yes, should there be a special way to attach a handler to a token without returning such a result? And what about composition of tokens, where handlers would return a promise for an array of handler results?
These exceptions are typically unwanted, so we definitely want them reported if no one handles them. All of the above calls do produce a promise that is indeed rejected when the respective handler throws:
ais the promisefinally(in the current proposal) produces an internal promise that is always resolved with the handler result (and rejected here),bis essentiallyinternal.then(() => promise, null, token)so it is cancelled here before it could be rejected (only ifpromisehas an associated token).cis the promise`dis a function, butsubscribeOrCallproduces an internal promise that is always resolved with the handler result.So there's always a promise that is getting rejected and could be tracked. However, in the case A the promise is typically part of some chain, and it is possible if not quite likely that they have a cancelled rejection handler attached to them that prevents tracking (see #5). In the case B, attaching handlers to
bdoesn't work as it is cancelled. The internal promise is not accessible but does have a cancelled handler attached to it - #5 again. In the case C, the promise is surfaced but usually doesn't get any handlers attached. In the case D, the promise is absolutely not accessible.Handling these rejections explicitly is only possible in the cases A and C.
The current proposal presents the idea that all these rejected promises are returned by the
cancel()call in an array to the canceller:res=[a, internalB, c, internalD]. The canceller (i.e. the actor that requests the cancellation) is thereby enabled to handle exceptions that happened during the cancellation. It also receives normalreturnvalues from the cancellation handlers.Does this make sense? Or is this absolutely insane? Are there any problems with leaking information? Is this useful at all?
If yes, should there be a special way to attach a handler to a token without returning such a result? And what about composition of tokens, where handlers would return a promise for an array of handler results?