[tilgovi]

Not necessarily. A callback function with the standard signature under the hood is implied. If the author is controlling flow into and out of these execution contexts there is no reason an error passed to the implicit callback cannot cause an exception to be thrown into the original execution. Throwing exceptions into coroutines is a fairly normal pattern.

[tlrobinson]

True, but the existing Node APIs don't do that, they return the error as an argument to the callback.

[snprbob86]

The wiki page says:

    // these two lines are equivalent
    await a, b, c, d = moo(1, 2, 3);
    moo(1, 2, 3, function(a, b, c, d) {} );

So I don't see why not...

    // ...these two lines would be also equivalent
    await error, foo = bar(1, 2, 3);
    bar(1, 2, 3, function(error, foo) {} );

[tlrobinson]

Exactly. The error object is a return value of the "await"-ed function, not an exception that's thrown.

Here's a concrete example. Normally in Node you do something like this:

  fs.readFile('/etc/passwd', function (err, data) {
    if (err) {
      // handle error
    }
    // normal processing
  });

The await version would look like this:

  await err, data = fs.readFile('/etc/passwd');
  if (err) {
    // handle error
  }
  // normal processing

Ideally it would look like this:

  try {
    await data = fs.readFile('/etc/passwd');
    // normal processing
  } catch (error) {
    // handle error
  }

[koush]

This is certainly something that is doable and crossed my mind, but I did not want to have the await be restricted to functions that conform to the typical return arguments. For now at least.

[dbrock]

How about

  try await foo = bar(baz)

as shorthand for

  await error, foo = bar(baz)
  if (error) throw error