Thanks Ron! Comments inline...
> · Once a callback has been registered for asynchronous notification
> of a cancellation signal, it can later be unregistered.
>
Yes, I see how this could be helpful.
> · Asynchronous notifications are queued and handled at a higher
> priority than Promise continuations.
>
> · The reason for cancellation can be explicitly supplied. If not
> supplied, the reason would be a generic “The operation was canceled” error.
>
What's the benefit of allowing a user-supplied error? (I assume that by
convention the reason should be an error type.) I don't see that feature
in .NET.
> Since “source.cancel()” is executed synchronously, one would expect that
> `p` would be rejected. If the notification were merely added to the same
> micro-task queue as Promise “then” tasks, `p` would be resolved first.
>
I agree that your example, as written, is counter-intuitive. However, is
it still counter-intuitive if I rewrite it like this?
// Suppose I have "cancelToken" and "cancel"
let p = new Promise((resolve, reject) => {
Promise.resolve(1).then(resolve);
cancelToken.promise.then(reject);
cancel();
});
Written like this, it seems to me that the ordering is as expected. Are
there use cases that require a higher priority, beyond user expectation
based on the API?
In .NET, cancellation notifications are executed synchronously, however
> this conflicts with the intent to ensure an asynchronous API is
> consistently asynchronous.
>
Right. The trouble I have with introducing an ad-hoc callback API for
cancel tokens centers mostly around the handling and propagation of
errors. In .NET, exceptions which occur inside of callbacks are propagated
synchronously to the caller via an AggregateException error collection.
But if the callbacks are truly executed asynchronously, where do the errors
go? Do they propagate out to the host, like HTML event handlers? It would
be unfortunate if no mechanism was provided by ECMAScript itself to handle
such errors.
Since we already have a well-defined and well-understood way to propagate
errors using promises, I would prefer to have the async registration
capability modeled as a promise, if possible. There is that "unregister"
issue, though...
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
