Cancel Promise pattern (no cancellable promises)

Igor Baklan io.baklan at gmail.com
Tue Jan 10 09:42:37 UTC 2017


> Um... This isn't much different than Bluebird's
`Promise.prototype.cancel`,
> admittedly the least optimal of all these so far.

Yes, very similar, in that it is propagated upward on "async-stacktrace",
and can be actually handled in [promise-executor](
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters).
But very different in a way how callbacks of "affected" promises should be
treated. As I can understand from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html) article - on cancellation
method invocation it always go into cancellation action (which is delivered
on that "3-rd rail", so no success neither failure callbacks are invoked
but consistency still preserved - finally callbacks still executed - which
is really nice option but ...). But what I say in this "interruption" idea,
that it should be up to [promise-executor](
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters)
what action should be taken on underlying promise (and in turn propagated
downward async-stacktrace). So that when you call
here ``somePromice.interrupt(someInterruptionConfig)`` it may end up with
any kind of results - success/failure/3rd-rail-cancellation - and it should
be specified in particular [promise-executor](
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters)
(generally in top-most promise in async-stacktrace) how to react on this
particular ``someInterruptionConfig`` passed into ``.interrupt(...)``
method. However I should admit that most likely "implementers" and "users"
of such functionality would prefer and intent exactly that behavior from
[bluebirdjs-cancellation](http://bluebirdjs.com/docs/api/cancellation.html)
, and would rather want always implement that kind of behavior by default,
but what I actually don't like from that - is that decision "how to
complete underlying/topmost-interrupted promise" is taking without "asking
[promise-executor](
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters)
what it thinks about it before(not after) canceling" (whether it "objects"
this abrupt execution, maybe it prefers to continue working and just ignore
this interruption signal, or may be it already has some default
success/failure result and would prefers to complete abruptly but with its
own default result etc).

So again what is not very good with [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html), that [promise-executor](
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters)
can not intercept this signal, and can not "preventDefault"-behavior, but
instead it is only notified that "everything(cancellation) already
happened" (as I can conclude from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html))

And finally, I think it is also very nice to have that cancellation with
"firm contracts" - which always/unavoidably cancels promises chain (for
example by the means of that 3-rd-cancellation-rail). But as for me it
would be also good to have that more "soft" functionality which delegates
to [promise-executor](
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters)
decision on which "rail" (success/failure/cancellation) and with which
actual "value" deliver that abnormal execution completion / cancellation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170110/2bd18e94/attachment-0001.html>


More information about the es-discuss mailing list