Let's take a simple asynchronous function
```js
const asyncFunc = (...args) => new Promise((resolve) => {
setTimeout(() => resolve(computeResult(...args)), 1000);
});
```
One problem in this example is that any error thrown by `computeResult` will
not be correctly handled. This can be solved wi
f.e.
```js
let resolve
let p = new Promise(r => resolve = r)
resolve(5) // resolves the promise.
resolve(4) // noop (in Chrome), but why not throw an error?
```
I only tested in Chrome, and I'm assuming it follows spec, but I could be
wrong.
I'm asking because it seems that throwing an error w
On Tue, Feb 28, 2017 at 10:12 AM, /#!/JoePea wrote:
> f.e.
>
> ```js
> let resolve
> let p = new Promise(r => resolve = r)
>
> resolve(5) // resolves the promise.
> resolve(4) // noop (in Chrome), but why not throw an error?
> ```
>
> I only tested in Chrome, and I'm assuming it follows spec, but
Why not using fill setTimeout API, also granting you args are those passed
at the invocation time and no possible mutation capable of affecting `
computeResult` could happen later on?
```js
const asyncFunc = (...args) => new Promise((resolve) => {
setTimeout(resolve, 1000, computeResult(...ar
On Tue, Feb 28, 2017 at 7:47 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
>
> Why not using fill setTimeout API, also granting you args are those passed
> at the invocation time and no possible mutation capable of affecting
> `computeResult` could happen later on?
>
>
> ```js
>
> con
In the first example, I haven't written this by accident:
> also granting you args are those passed at the invocation time and no
possible mutation capable of affecting `computeResult` could happen later
on?
which is why I've shown both examples, the before `setTimeout(resolve,
1000, computeResul
Also, making promise resolution idempotent makes dealing with things way
easier. Similarly, most deferred libraries ensure their resolution is
idempotent.
On Tue, Feb 28, 2017, 13:20 Tab Atkins Jr. wrote:
> On Tue, Feb 28, 2017 at 10:12 AM, /#!/JoePea wrote:
> > f.e.
> >
> > ```js
> > let resol
Although now that I think about it, it wouldn't have to care about the
promise state, `resolve` and `reject` could just throw if they're invoked
more than once.
On Tue, Feb 28, 2017 at 1:35 PM, Jordan Harband wrote:
> That seems like it would allow synchronous observation of Promise state -
> co
That seems like it would allow synchronous observation of Promise state -
consider:
```js
function isResolved(promise) {
try {
new Promise((resolve) => {
resolve(promise);
resolve();
});
} catch (e) {
return true;
}
return false;
}
```
On Tue, Feb 28, 2017 at 12:
On Tue, Feb 28, 2017 at 8:14 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> In the first example, I haven't written this by accident:
>
> > also granting you args are those passed at the invocation time and no
> possible mutation capable of affecting `computeResult` could happen lat
> it was obvious from the example that it's important that `computeResult`
isn't called until after the delay
I was just underlying possible side effects. TBH, I don't even know why
forcing a delay to an async function would be needed but yeah, definitively
on the same page.
I am also a bit again
BTW, there's still usefulness of making resolution/rejection idempotent and
never throwing. IMHO, I'd just like to see this die.
-
Isiah Meadows
m...@isiahmeadows.com
On Tue, Feb 28, 2017 at 4:36 PM, Jordan Harband wrote:
> Although now that I think about it, it wouldn't have to care about
12 matches
Mail list logo
