>Not only is this a ton of boilerplate<p>Bluebird has an overload of catch() that takes in a parameter for the error class. <a href="https://github.com/petkaantonov/bluebird/blob/master/API.md#catchfunction-errorclassfunction-predicate-function-handler---promise" rel="nofollow">https://github.com/petkaantonov/bluebird/blob/master/API.md#...</a><p>>I don't care about losing the stack (which is inherent in any async work).<p>Bluebird gives stack traces across async frames.<p>>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.<p>This is true, although for errors thrown explicitly with throw your debugger will stop at the actual throw site.<p>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.<p>>It's cool, I just don't understand why everyone is so excited about a simple syntactic improvement.<p>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.<p>Edit: (And of course await is much clearer than a yield and remembering to wrap the outermost async function in spawn())
If it's any consolation, I also dislike promises, though I don't know that much about them. I feel they don't solve the problem they set out to solve, "callback hell" or cleanly interleaving async and sync code together, and I don't find their syntax aesthetic. I feel JSONP, message passing and state machines are cleaner. I'm unsure why many love promises, and was surprised by the level of what I'm only comfortable describing as "standards fever" over the emergent promises spec.<p>I also think arrows are cool.<p>Ah, that was refreshing. Thanks you for having the courage to buck the promises trend, which contributed to inspiring me to speak my mind as well! :)<p>BTW -- your karma is enormous. What's with that?
The first time I used Promises (and really, the first time I did any serious work in Node), I prototyped an isomorphic web server:<p><a href="https://github.com/appsforartists/ambidex/blob/master/src/Ambidex.server.js#L300-L305" rel="nofollow">https://github.com/appsforartists/ambidex/blob/master/src/Am...</a><p>In three different places in that file, you'll find a Promise that ends in ".catch(error => console.error(error.stack))`. Before I learned that bit of boilerplate, I'd spend an hour staring at my screen wondering why things were silently broken.<p>It's mindblowing that errors are implicitly suppressed by default with Promises. console.error ought to be automatically invoked for any error that makes it to the root scope without a .catch() (just like it is with sync code).
> A newbie to JavaScript will write that code, and be totally bewildered when nothing happens.<p>The above statement is applicable to a <i>huge</i> number of situations in JS. I'm surprised that so little has been done about it.
Agreed. An exception being silently caught and ignored by es6-promise was the culprit of a bug hunt that took a lot longer than it could have if the exception had automatically percolated to the console. I know now about the infinite try-catch of Promise so it won't be as much of an issue, but I think it would be better if the exception were uncaught (or re-thrown) if there are no more handlers on the promise chain. (Not sure how the library would know that though)
Yep. It is quite annoying. I remember working with some promise-library (bluebird iirc), which completely replaced error handling, including the stack traces. I was working with transpiled code, and the browser could always give me really helpful stack traces, for normal code, because of the .map files. That libraries stack traces were useless and made debugging frustrating and time consuming.
I ended up removing instances of try catch and also setTimeout 0 (or equivalent nextTick) in the promise library I use. Those two things caused me enough grief on several occasions to force my hand and modify the library's implementation. The setTimeout one especially baffled me... The straw that broke the camel's back for me was how it broke IndexedDB transactions
> It's cool, I just don't understand why everyone is so excited about a simple syntactic improvement.<p>async-function-star is a pretty interesting concept that it at least theoretically makes possible; AKA being able to both yield <i>and</i> await in a function.