Here's my attempt at a slightly less contrived example:
router.get('/users/:id', async (ctx, next) => {
const user = await db.getUser(ctx.params.id)
if (!user) return ctx.send(404)
let data
if (user.admin) data = await api.getSomeData(user)
return ctx.render('show_user.html', { user, data })
})
That's actually one of the whole points of using promises: it doesn't swallow errors.
Errors bubble up to the top-level. It's the old callback-style that swallows errors unless you manually handle them every time. It's one of the chief advantages of promises.
In my case, errors bubble up to error-catching middleware and, at the end of the chain, into a 500 error that gets logged.
The errors won't be swallowed only in two cases: either if router.get actually supports promises (thus catches all the bubbled errors on its own) or if you have unhandledRejection global listener.
Some node versions do show unhandled rejections automatically (e.g. v7.x), but that is getting deprecated soon.
So, there's quite a real risk of quiet failures in that bit of code.
Upd. Looks like even though the unhandled rejections warnings are getting deprecated, the rejections themselves will actually stop the code execution with non-zero exit code! Which means most of the issues I had with that code are gone (which is awesome)
Of course the code in my example handles promises. It's actually an example of koa code.
Not sure why that is a "real risk". You generally want to be using promises with libraries that support them. That's why I wouldn't use promises in vanilla Express as my daily driver abstraction.
Compare this to callbacks where there's an actual real risk of silent error dropping any time you forget to `next(err)` or `.catch(handleErr)`, which is something you have to carry around for the life of the project instead of my example, where you choose a framework (once) that supports them.
I'd say it's a great demo and addressed all your concerns so far since it's this kind of context where async/await really pays off compared to the logFetch example.
I really hope that this release means that koa2 will release soon.. been a little painful to determine which versions of what modules are supported. Really enjoying koa2 though.
yeah, now I'm having trouble getting webpack + hmr working with koa2 in node 7.6... the webpack page mentions issues with v7, so trying what I had in v6, will see if I can get it working.. :-(
Looks like it might be a good time to move code from v4 (that had all those swallowing issues) to v7 and just forget about that. Promises sure came a long way :D
Thanks... may have to take the time to have a couple different webpack configs so I can target the latest chrome (and edge 15, safari 10.1, etc), separately from the es2015 builds.
It's been coming for a while, but finally getting browsers that don't need nearly as much fluffy goodness from babel, which I'm happy to see.