>Not only is this a ton of boilerplate Bluebird has an overload of catch() that takes in a parameter for the error class. https://github.com/petkaantonov/blueb

>Not only is this a ton of boilerplate Bluebird has an overload of catch() that takes in a parameter for the error class. https://github.com/petkaantonov/bluebird/blob/master/API.md#catchfunction-errorclassfunction-predicate-function-handler---promise https://github.com/petkaantonov/bluebird/blob/master/API.md#... >I don't care about losing the stack (which is inherent in any async work). Bluebird gives stack traces across async frames. >but it breaks an important feature of JavaScript debuggers: break on exception. If you have break on exception enabled, and you make an error inside getValue, it now pauses on the throw in the above code instead of inside getValue where you actually made the mistake. This is true, although for errors thrown explicitly with throw your debugger will stop at the actual throw site. The good thing is the original exception's stack is maintained, so you know when it came from and can set a bp next time. >It's cool, I just don't understand why everyone is so excited about a simple syntactic improvement. The excitement is related to the comparative ES5 code (state machine) that would be needed to achieve it, not the ES6 code (generators). Everyone knows that async/await is a simple wrapper around generators - LukeH's original proposal describes it as such. Edit: (And of course await is much clearer than a yield and remembering to wrap the outermost async function in spawn())