Why throw a CancellationError if promise is used after cancellation

[Bernhard Poess]

In a web app that I am currently working on we are trying to use bluebird3's revamped promise cancellation (http://bluebirdjs.com/docs/api/cancellation.html). We were excited about the "don't care" semantics that the API promised but quickly found out it's not quite as "don't care" when it came to using a promise after cancellation.

Consider the following scenario. Library A hands exposes an interface that returns Promises that resolve when an async request initiated by the caller of the library finishes. Let's assume that a client uses our library A to initiate a request and gets a promise (promise1) returned.

In addition the client supports user initiated actions (say from a button click) that will result in a given callback called (let's call it buttonClickCb).

const promise1 = LibraryA.request('request descriptor');

// Callback that will get called asynchronously when a button gets clicked
function buttonClickCb() {
   promise1.then(function(result) {
      /* something smart here */
   });
}

// Destroy handler that runs asynchronously if the current client view gets destroyed
function onDestroyCb() {
   promise1.cancel();
}

this seems like a valid pattern to use. If a view gets destroyed (say a user navigating away from a page in an SPA) I want to cancel outstanding requests.

However with current bluebird3 cancellation semantics this is impossible to implement without checking in every callback whether promise1 has already been cancelled which forces knowledge about cancellations into a lot of places that shouldn't have to know about them.

Note that this is a very simple example pattern, it gets complicated quickly especially if say the promise returned gets passed to another library.

My question is first to understand the motivation behind the current semantics and as a follow up whether there have been any talks in the bluebird3 community about changing them to true "don't care" semantics.

Thanks!

-Bernhard