Serious question - why is cancelling a promise a reasonable use case? Doesn't cancelling potentially invite non-deterministic state into your program? If not, what would be the difference from throwing?
[0] https://docs.google.com/presentation/d/1V4vmC54gJkwAss1nfEt9...
[1] https://github.com/tc39/proposal-cancelable-promises/blob/0e...
The user no longer cares about the original request. You could just discard the data when it arrives, but what if it's an expensive request for the client, or server, or both? You'd want a way to opt out of all that extra load on the system.
(Not really sure how to parse non determinism and throwing being related to cancelling promises)
And yes, you can absolutely handle it by throwing an exception. But cancellation is such a common mechanism that you'd want to have 1) a standard exception type that can be used to indicate it, and that other async operations can handle in a composable fashion, and 2) a standard mechanism to request cancellation cooperatively, again, so that various layers can collaborate on handling a high-level cancellation request all the way to the lowest level like an I/O read.
And that's what this proposal was all about.