Alternative way to achieve cancelable promise

I want to find a way to replace cancellation token in the current [stage 1 cancelable promise proposal](https://github.com/tc39/proposal-cancelable-promises) with an alternative way which does not require passing an additional parameter. Here is a short representation of [my current

Re: Why Number(symbol) crashes?

To be honest, introducing new throw-on-invalid value behaviour to existing function that didn't throw before looks rather like a bad design for me. Personally I wouldn't abandon accept-anything behaviour of Number, but rather add method Number.from that will throw on all values that shouldn't be

Re: Try/Catch always needed for await?

When the await throws an exception that's not caught by a try/catch, the promise returned by the `async function` ends up rejected - and you have the identical scenario as a promise with an unhandled rejection. node has been discussing adding "crash on garbage collection of an unhandled

Re: Why Number(symbol) crashes?

Allen, thanks for comprehensive answer, it's clear now. Still, I must agree with Michał, that introducing such inconsistency to language doesn't give good impression. It's like we try to build other language on top of language which we can't change. It's now even more difficult to explain

Re: Try/Catch always needed for await?

On Fri, Oct 14, 2016 at 11:25 AM, Alan Johnson wrote: > Having unexpected errors be silently swallowed is definitely a problematic > property of promises, which you have to guard against. I didn't think this was the case with await. If a promise rejection is not caught the