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
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
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
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
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
5 matches
Mail list logo