Why do we throw cancellations?

[markcellus]

I think its weird to throw a cancellation. You throw exceptions. And cancellation (even in the light of promises) doesn't really feel like an "exception" to me. So why do we treat it like one?

[inikulin]

https://github.com/domenic/cancelable-promise/blob/master/Not%20an%20Error.md#why-modeling-cancelation-as-an-exception-type-works

[markcellus]

Yeah I read that but it assumes that we should classify cancellations as an exception type, but it doesn't really give any strong reasons why. After all, essentially what it sounds like is that we're trying to classify it as an exception type but don't really want to respect what an exception is really used for.

We say things like:

Once an operation is canceled, any fulfillment or rejection reactions to it are no longer valid.

But we're classifying it as an exception... and exceptions trigger rejections. It's how promises are rejected today.

we do want cancelation to "propagate" similarly to how rejection with an error propagates.

But then we say its not an error. Propagate it as an error but not really an error?

Outside of seeming contradictory, it seems like the proposal is contrived and slightly forced into this odd "Error-but-not-really-and-error" space when I think it would be much more clear to just make a new space for cancellations

[inikulin]

If you assume that errors are subset of exceptions everything becomes pretty clear IMO

[markcellus]

Eh, thats just my point. Is it really good to make that assumption? Would love to know what other core JS contributors think. :)

On Wed, Aug 24, 2016, 8:58 AM Ivan Nikulin notifications@github.com wrote:

If you assume that errors are subset of exceptions everything becomes pretty clear IMO

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/domenic/cancelable-promise/issues/49#issuecomment-242053642, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYUBFmghowaS6BUIr0i-GfELpFnFw04ks5qjD_qgaJpZM4Jr5Ta .

mark

Sent while riding a hoverboard... heyimmark.com :)

[bergus]

Have a look at it from this perspective:

• Cancellation is not an exception (it's not exceptional)
• Cancellation is a rejection, because the promise is never fulfilled

think it would be much more clear to just make a new space for cancellations

Essentially this is what the proposal does. The catch is that cancellations need to call rejection handlers to be compatible with code that does not know of cancellations. Maybe you want to have a look at my alternative proposal and see if you find its reasoning more intuitive.

[domenic]

This was a requirement to achieve committee consensus. (All new abrupt completion types must be modeled as exceptions, caught by catch blocks.) I don't really like this design, but it's mandatory for this proposal to move forward.

Happy for the discussion to continue, but going to close this since it isn't an issue with the current spec.

[domenic]

@bergus let me be very explicit: this is not the place to advertise your alternative proposal. That is es-discuss and so forth. If you continue we will have to start moderating your participation here.