Chapter: Promises for asynchronous programming

[VernonHawk]

1. Typo in 37.1.4. States of promises

   • Once a Promise is settled, the settlement value (result or error) is cached. Thus, if .then() or .catch() are called after the settlement, they receive the ~chaed~ cached value.

2. A mistake in 37.6.4. Nesting per se is not evil

   In the following code, we benefit from ~not~ nesting:

db.open()
.then(connection => { // (A)
  return connection.select({ name: 'Jane' })
  .then(result => { // (B)
    // Process result
    // Use `connection` to make more queries
  })
  // ···
  .catch(error => {
    // handle errors
  })
  .finally(() => {
    connection.close(); // (C)
  });
})

But this code shows an example of good nesting.

[rauschma]

@VernonHawk Thanks! Both things will be fixed in the next release.

[maksverver]

“37.6.4 Not all nesting is bad” shows how nesting can be beneficial. The code sample uses finally(), which hasn't been discussed before, so it's not obvious what the code does.

The finally() method should probably be discussed earlier in the chapter.

For completeness sake, it might also make sense to mention the second (optional) parameter to then().

[Vishwa-code]

In 37.1.1 It's mentioned, "A Promise-based function returns a Promise and sends it a result or an error (if and when it is done). The Promise passes it on to the relevant callbacks.", (But the promise based function 'addAsync()' only returns Promise and it is inside the promise the result or error is evaluated and passed on via resolve or reject, which is handled by call-backs of .then() or .catch().) The aforementioned statement in quotes is confusing. Can you please make it more clear by being more specific with an example.

[danzelito]

40.5.2.3 A simple implementation of Promise.all() function all(iterable) { ... const result = []; // (instead of let result;)