Igor Baklan (2017-01-10T09:42:37.000Z)
io.baklan at gmail.com (2017-01-10T09:47:12.907Z)
> 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 prefer 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.