Alternative way to achieve cancelable promise

[Kagami Rosylight]

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 
thought](https://github.com/SaschaNaz/cancelable):

```ts
// A cancelable object supports new `Symbol.cancel`.
// `object[Symbol.cancel]()` will cancel any tasks related to the object.
interface Cancelable {
  [@@cancel](): void;
}

interface Promise extends Cancelable {}
```

```js
// Here, a new `chain` object from promise constructor callback will
// help chaining cancelable tasks and provide cancellation related
// helper functions.

function foo() {
  return new Promise(async (resolve, reject, chain) => {
await nonCancelableSubWork1();
chain.throwIfCanceled(); // This line will throw `Cancel` object if the 
promise got a cancellation request
await nonCancelableSubWork2();
resolve();
 });
}

function bar() {
  return new Promise(async (resolve, reject, chain) => {
 // This `chain()` call will register foo() to the cancellation chain of a 
promise instance
 // and will propagate cancellation to the chained tasks.
 // The chain can receive any object that supports `Symbol.cancel`.
 await chain(foo());
 await chain(baz());
 });
}

const promise =  bar();
promise.cancel(); // This will cancel `bar` call and the cancellation will 
propagate to `foo` and `baz`
```

And with some syntax sugar for readability:

```js
cancelable function foo() {
  // `chain` is a keyword inside cancelable function blocks
  await nonCancelableSubWork1();
  chain.throwIfCanceled(); // similar form like `new.target`
  await nonCancelableSubWork2();
}

cancelable function bar() {
  chain foo();
  chain baz();
}

const promise = bar();
promise.cancel();

cancelable function baz() {
  try {
chain baw();
  }
  else {
// try-else block will catch cancellation, as the current existing proposal 
does
  }
}
```

I think this will achieve easier and more readable flow of cancelable tasks, 
what do you think?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why Number(symbol) crashes?

[Michał Wadas]

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 coerced to number.

On 15 Oct 2016 1:23 a.m., "Allen Wirfs-Brock"  wrote:

>
> > On Oct 14, 2016, at 11:02 AM, Claude Pache 
> wrote:
> >
> >
> >> Le 11 oct. 2016 à 11:07, medikoo  a
> écrit :
> >>
> >> I was searching the archived but wasn't able to find the answer.
> >>
> >> What's the reasoning behind having Number(symbol) crash instead of
> returning
> >> NaN (as it's in case all other non-coercible values?). It feels not
> >> consistent.
> >>
> >> If someone can point me to some discussion that provided the reasoning
> I'd
> >> be grateful
> >>
> >
> > I believe that the reason of the inconsistency is more an accident of
> history in the development of ES6 than a well-reasoned design decision.
> Here is my understanding:
>
> No this was an intentional design decision. There is no  obvious or
> natural Number value corresponding to symbol values. Rather than inventing
> some arbitrary conversion rule (for example producing NaN) TC39 choose to
> throw an exception for such conversions as they are a clear manifestation
> of some sort of program bug.
>
> Note that the coercion rules for the original JS primitive types were
> created at a time when JavaScript did not have an exception handling
> mechanism and hence all operations were required to produce some value.
> Throwing exceptions for unreasonable Symbol coercions is intentionally
> inconsistent with the handling of the original primitive coercions and is
> intended to set a new precedent  that will be applied to any other new
> primitive types that might be added to ES in the future.
>
> Allen
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Try/Catch always needed for await?

[Jordan Harband]

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 rejection", but the reason this is possible for them to add is
because by the time something gets garbage collected, nothing in JS can
possibly add a later catch handler - and this would cover promises and
async functions *identically*.

In other words, async/await *in no way whatsoever* changes the discussion
around unhandled promise rejections.

On Sat, Oct 15, 2016 at 11:09 AM, Jordan Rome  wrote:

>
> 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 await throws an exception and doesn't execute code below in the
> async function. Also, I believe Node is soon adding support for killing the
> process if a rejected Promise is not caught before it's garbage collected.
> If this is true why the importance of using try/catch with await, don't we
> want programmer errors to be noisy so we can fix them?
>
> --
> Best,
>
> Jordan Rome
> www.jordanrome.com
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why Number(symbol) crashes?

[medikoo]

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 language behaviors to newcomers.



--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Why-Number-symbol-crashes-tp359554p359653.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at 
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Try/Catch always needed for await?

[Jordan Rome]

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 await throws an exception and doesn't execute code below in the
async function. Also, I believe Node is soon adding support for killing the
process if a rejected Promise is not caught before it's garbage collected.
If this is true why the importance of using try/catch with await, don't we
want programmer errors to be noisy so we can fix them?

-- 
Best,

Jordan Rome
www.jordanrome.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss