Hacker News Reader

Comment by nailer | Hacker News Reader

For anyone unfamiliar with JS, async/await is about the best JavaScript will ever get:

    var orders = await getJSON('/users/joe/orders');

No callbacks, promises etc (Edit: that you have to look at, as other posters note the implementation uses promises in the background).

You still have to explicitly say you want to be async, so it's not quite as good as non-blocking IO in something like Elixir, but it's the future as far as JS goes.

View on HN

There are promises there, it just hides it. All async functions return a promise, and `await` works with promises builtin. It's basically the same thing as generators, without the `function*` syntax.

Which is unfortunate because async/await only works with promises, and if you want any other async model (like one that doesn't eat errors all the time) you can't use it. Luckily, generators are fine.

That's correct, I've edited my post to be clearer. Thanks.

I'm confused, I don't know what type of errors a promise eats. If you're chaining together promises returned by other routines, especially with async/await, then error propagation and handling is very natural. If you're creating a promise using `new Promise` then you can use reject to propagate errors. How does this fall short of other async models?

The problem isn't the propagation, it's the propagation by default. He wants errors that occur in development to pop a stack trace as soon as the error occurs without needing to attach a .catch handler.

But... it's an async call. The error is going to happen as part of the event loop. That's inherent to the nature of async. If you want to get the error before it happens, you'll need a time machine.

Its not about getting errors before they happen:

http://jlongster.com/Stop-Trying-to-Catch-Me

This requires the first method running in the stack to handle the failed promise and rethrow as an exception. It can be done today manually. But with async/await this will be done automatically.

I think you you (he?) needs RejectionEvent[0]. If that is so, it is a solved problem :)

Basically, implementations log the error to the console and raise the PotentiallyUnhandledRejection event if an error occurs inside a promise and no .catch handler was attached. If a .catch handler is attached _after_ the error is already logged, then a RejectionHandled event is raised. You can listen to those global events (the context is process in node, and window in browser, I think).

0: https://github.com/domenic/unhandled-rejections-browser-spec...

What do you mean by "if you want any other async model you can't use it"? I know you can write whatever code you want, but promises are supposed to be the standard way of signaling completion of asynchronous operations in javascript.

This is the same as saying that "arrow functions only works if you want to represent functions".

Also, promises don't eat errors. It's the code using those promises that forget to handle them.

The async/await fixes that by unwrapping those errors for you. Any errors in an "await expression" will be thrown as exceptions up the stack.

> What do you mean by "if you want any other async model you can't use it"?

Promises are not the only way to do async work in JS, as much as some people like to say that. You have observables and channels, which are more powerful because they handle streaming.

There are proposals to make async/await more composable: https://github.com/jhusain/compositional-functions. TC39 is aware of this but I'm not sure if they are going to fix it or not.

> Also, promises don't eat errors. It's the code using those promises that forget to handle them.

They literally do. They run your code in a try/catch block and store the error away, and you have to remember yourself to manually throw it later. You shouldn't be forced to run code inside a try/catch. http://jlongster.com/Stop-Trying-to-Catch-Me

Promises and observables are related but operate differently, just as a single string relates to an array. Promises represent a single operation, there is nothing wrong with the abstraction itself.

As for the errors, I see what you mean. But at the same time this is an issue with trying to write async operations with sync constructs, something all "old" languages need to do. Async/await is a pattern that does that in languages that can't do it implicitly by requiring an explicit declaration. You don't need to write try/catch with async/await. You will get the exception propagated through the stack automatically.

In some way, promoting the use of "await" actually reduces the chance of an exception floating away into the ether. The "thread" joins back, both on success and on failure. And because promise errors are like exceptions, it's probably not a great idea to signal commonly-occurring conditions through them (instead using sentinel values like nulls, etc); so there isn't a huge pressure to try-catch every single thing.

Also, there is fundamentally nothing wrong with a promise error that never gets handled. It's an "if a tree falls in the woods" kind of thing, no? I will concur that it's not exactly beginner-friendly, though.

>I don't care about awkward .then() syntax. I don't mind automatic error propagation. I don't care having to call .done() on a promise chain. I don't care about losing the stack (which is inherent in any async work). I care that promises grab all errors, just like try/catch.

You should stop caring about that and start caring about the other stuff.

"Breakpoint on exception" still works, albeit slightly altered, and in any way it's a minor detail compared to the far better mental model for code execution that async and promises bring.

>I want to make stupid typo errors and have them appear as normal errors, not caught by promises.

For stupid typo errors use a linter and/or a transpiler like babel in the first place.

>It's cool, I just don't understand why everyone is so excited about a simple syntactic improvement.

Because better syntax brings code closer to how we think, and reduces errors.

> They run your code in a try/catch block and store the error away, and you have to remember yourself to manually throw it later.

The compiler probably does that for you, honoring catch blocks. It does in C#, I see no reason why it wouldn't in ES7.

So, async/await is actually less likely to eat exceptions.

> Promises are not the only way to do async work in JS, as much as some people like to say that. You have observables and channels, which are more powerful because they handle streaming.

Let me just try and translate that into sync-land: "Single value variables are not the only way to do work in JS, as much as some people like to say that. You have arrays and queues, which are more powerful because they handle multiple values"

(my point being, different abstractions are useful for different things and/or in different ways)

> There are proposals to make async/await more composable: https://github.com/jhusain/compositional-functions. TC39 is aware of this but I'm not sure if they are going to fix it or not.

I agree, but I don't think we need async/await at all. http://spion.github.io/posts/es7-async-await-step-in-the-wro...

> You shouldn't be forced to run code inside a try/catch.

How is throwing on typos useful? The real solution for that isn't letting errors get through. Its having a type system like TypeScript or Flow plus using a sensible library like bluebird that reports rather than swallows up unhandled errors by default. Afaik errors from native promises are reported to the console in most browsers. And there are also tools like this: https://github.com/emberjs/ember-inspector/wiki/Promises-Tab

Allowing thrown errors to propagate synchronously will destroy many contractual guarantees that make promises useful in nodejs. For example, we would have to remove this entire section in Bluebird: https://github.com/petkaantonov/bluebird/blob/master/API.md#... and instead fall back to process crashing and restarting. Lack of error catching is what makes node unable to provide a safe solution to the crashing problem (and domains capture errors in both directions of the call stack which leads to problems inside node internals). Promises neatly solve that by providing a sensible error capturing and propagation model that isolates node internals from promise code: https://github.com/petkaantonov/bluebird/issues/51

«They run your code in a try/catch block and store the error away, and you have to remember yourself to manually throw it later.»

Browser native Promises and their corresponding Dev Tools work exactly how you would expect and surface uncaught exceptions in Promises. Browsers that support async/await will especially be incentivized to provide strong asynchronous exception handling in their Dev Tools.

It's just tough to polyfill that behavior without bringing the JS synchronous code world to a halt. A good Promises library/polyfill will at least attempt to console.log uncaught exceptions when they happen.

So conceptually, async/await is just replacing the `await someMethod()` statement with the first argument to `resolve` or calling `catch()` with the first argument of `reject`?

Almost. In simple terms:

  // this
  var x = await promise;
  callSomething(x);

  // translates as
  promise.then(x => callSomething(x));

Under the hood, the entire "async" function is turned into a state machine instead of creating a lot of callbacks. It's more efficient it can do some optimizations that would be boring to do manually.

For example, if the translation were simply "turn into callbacks", this:

  var p = getJson();
  var x = await p;
  var y = await p;
  var z = await p;

would translate to something like :

  var p = getJson();
  p.then(o => { var x = o; });
  p.then(o => { var y = o; });
  p.then(o => { var z = o; });

but instead, the code runs more like this:

  getJson().then(o => {
    var x = o;
    var y = o;
    var z = o;
  });

I say runs like because the compiled code is more complex than that, it will still call functions, etc. It will also handle exceptions, which would add a lot of boilerplate to this code. But have in mind that because this is generated by the compiler, this code will in most cases be more efficient than anything you try to write by hand.

Thanks.

So conceptually, it's what I described; but in practice, it's optimized?

Yes. Also, you can read and debug more easily.

It also allows for workflows that are really hard with promise chains alone, even if what it does isn't so simple..

    while (somecondition) {
      try {
        await sleep(1000);
        somecondition = await someAsyncAction();
      } catch(err) {
      }
    }

Doing retries, or loops against promise actions are really cumbersome with promises directly, but with async/await becomes much more clear in terms of action and intent.

You can do this today with generators.

To use generators, I need something like Babel, so I may as well use async/await.

That said, it isn't too hard to write re-usable helpers for promise based control flow, in a similar manner to what async.js does for callbacks.

    function iff(condition, method) {
        return Promise.try(condition).then(result => {
            if (result) {
                return method();
            }
        });
    }

    function whilst(condition, method) {
        return iff(condition, () => {
            return Promise.try(method)
                .then(whilst.bind(null, condition, method));
        });
    }

    whilst(someAsyncAction, Promise.sleep.bind(null, 1000))
        .catch(err => {
            // ...
        })

Naturally you wouldn't want to re-implement all of this control flow every time you need it. But the end result is not too much boilerplate.

How does async/await eat errors?

    try {
        await do_thing();
    } catch {
        // works
    }

http://jlongster.com/Stop-Trying-to-Catch-Me

I don't really agree with the points this post puts forth, but I also don't really think this is the place to discuss it.

This is a great place to discuss it.

I just didn't want to get into the weeds about why his blog post is wrong here. In any case, his arguments against try...catch are silly. Syntax errors are not an argument against them, because you can easily detect them with other tools (and should be doing so). In practice, the only errors that will bubble up to your try...catch are ones about the async operation, not "typos".

About the points you make on your post, once async/await is implemented in browsers, you will be able to await run() directly, causing the exception to be thrown in the console.

The fact that you call a method that returns a promise but don't check this promise may be a little confusing to someone new to the language, but it it's not a flaw in the design.

In c#, any attemp to call a method that returns tasks (promise) without an await or a .continueWith (.then) causes a compiler warning. It's just a matter of time for tooling in the browser to keep up.

> About the points you make on your post, once async/await is implemented in browsers, you will be able to await run() directly, causing the exception to be thrown in the console.

I don't think you're right, unless TC39 has changed their minds. I argued hard for a top-level `await` but was strongly fought back.

If you can call into an async function in a way that immediately throws errors (that means that we can literally check the stack if the current async function should just throw the error), then I'm all good.

Indeed that might be the case. There are ES6 features implemented in chrome that don't work in the console (eg. classes). Still, it doesn't mean the language or the feature is doomed.

You have exactly the same issue with setTimeout. Errors will be thrown when the function runs, not when you schedule it. The problem you're describing is not an issue, and that's why today there are linters and compilers.

I'm not sure about the no promises and no callbacks part.

The similar line they use in their examples doesn't define a separate getJsonAsync function in the "Asynchronous city" section (and, as far as I can tell, there's no native getJSON function). That, and the fact that the line immediately preceding the await call has a comment that says, "just have to await the promise!", leads me to have to assume they used the function defined in the promises section, which of course uses promises. And, in order to define that promise, they do have to use three callbacks.

With functions and just callbacks I can make one-liners for fetching data too if I abstract away all the stuff that actually does the fetching of the data:

    getJSON('/users/joe/orders', function(orders) {} );

The parent exaggerated a little. async/await does use promises. In fact, it's built around them.

All async functions return promises, and all await expressions await on promises. Currently on babel implementation with facebooks's regenarator it seems to work on any "thenable", because I got it working with jquery and angular promises.

Depending on which transforms you enable, you can also eliminate Regenerator and use native ES6 promises and generators. E.g: https://gist.github.com/callahad/b99c83d6d9fd675137b7

Promises are sufficiently supported in the latest versions of all major browsers, and Generators are almost there. They're supported in Firefox and Chrome, behind a flag in Edge, but unsupported in Safari.

But if you're targeting Node 4.0, you might as well transpile down to ES6 instead of going all the way to ES5 and pulling in Regenerator :)

> as far as I can tell, there's no native getJSON function

There is a standard, native fetch() function which is pretty darn similar: https://hacks.mozilla.org/2015/03/this-api-is-so-fetching/

What's so good about it? I still want to fire some kind of callback when it's done. Or am I missing something?

I can't see either - would be nice to see\understand a little more what's so special about it.

When it's done, you will have the value in orders variable. If you can do something with it - just do it in new line in the same scope. You can also use catch exceptions using standard try catch block.

It's just sugar, and allows people to write JS do to this in a more consistent manner.

You only want to fire a callback because that's how you did async previously. In reality, all you want is async.

Reply on news.ycombinator.com