Should we separate abort/cancel and ignore?

[otakustay]

In some common cases, we expect a special state of promise, in which:

No handler is executed when the promise is fulfilled

Such case could be a not-wanted fetch process, like:

var fetching = fetch(url);
fetching.then(displayData);

// Since user navigates to another page, this fetch is not wanted anymore,
// however it could be continue and results in a local cache with the Expired header,
// so we do not abort it, and we do not want our reject handlers execute
page.on('exit', fetching.ignore);

For similar case, we may:

1. Add a ignore() method to put a promise in a ignored state
2. Reuse the cancellation spec but allow consumer to specify wether to reject the promise
3. Add a detach(handler) method to detach a handler so that each consumer can only manage handlers from its own

or I may put the issue in wrong place?

[bergus]

Notice that my Cancellation Token+ draft featues exactly this:

var fetching = fetch(url);
var display = fetching.then(displayData);

page.on('exit', function() { display.cancel(); } // `displayDate` would not be executed
                                                 // (if it hasn't already)

[otakustay]

I see in Cancellation Token+ the cancel method still reject the promise with a CancellationError, in my case I need such a state that the promise is not rejected but none handlers would be executed, in which I call it ignored

The reason that I doesn't want a rejection-based cancel method is that in many (maybe bad) practices we do not attach a catch handler to a promise, we just add a global error handler such as windows.onpossibleunhandledrejct to log any rejection of any promises, in this case a cancel call could result in unexpected log entries

Also I see the CancellationError approach may solve the unexpected log problem, we just ignore any rejections with a CancellationError as reason, so maybe a ignore() method is totally unneccessary?

[bergus]

No, the promise is only rejected for later then calls (which need to be notified that the promise had already been cancelled in the past). The handlers that were initially registered before the cancellation will not be executed, as they are cancelled/"unregistered" themselves before the attempt to cancel would succeed.
I think I'll need to reword the draft a bit, gonna do that these days…