A great pattern with ES2017 async/await is:
async function () {
try {
var result = await some_promised_value()
} catch (err) {
console.log(`This block would be processed in
a reject() callback with promise patterns
but this is far more intuitive`)
return false // or something less obtuse
}
result = do_something_to_result(result)
return result;
}
Being able to handle errors like that is really nice. But say I want to asynchronously get a value I'd like to protect it from reassignment (eg: a database session), but I still want to use the async/await pattern (purely because I think it's far more intuitive).
The following won't work because const is block scoped:
async function () {
try {
const result = await get_session()
} catch (err) {
console.log(`This block should catch any
instantiation errors.`)
return false
}
// Can't get at result here because it is block scoped.
}
Of course you could execute the rest of the function within the try block, but then you risk errors getting caught that should be let fall through somewhere else. (For example I hit this challenge writing tests where errors like test failures need to fall back to the test suite but wanted to handle driver instantiation myself. Perhaps I'm falling into some kind of anti-pattern here by not letting those errors fall back to the test suite.)
The simple answer obviously is don't use that pattern here. Use Promises and callbacks instead. Or use a var and avoid block scoped const and let. But I like the benefits of reassignment protection and block scope for other considerations.
[question]: Is there a way to wrap an await/async try/catch block to every function? Seems to be one potential solution, but doesn't quite come up as readable as try/catch. The fact that try/catch doesn't break function scope and I can use return from within a try/catch block seems to me to be more in line with the spirit of async/await bringing a more procedural-looking logic to asynchronous code.
Ideally you'd want to do something like const x = await y() catch (err) or const x = await y() || fail But I can't think of anything with a similar flow that's syntactically correct.
UPDATE: As suggested by @jmar777 below another alternative is:
const x = await y().catch(() => {/*handle errors here*/})
Which is probably the closest I've found to those last two examples in practice. But it breaks the return scope that blocks downstream execution in the examples above. Which is a nice synchronous-like way of handling things.
Each solution has its trade offs.
I've manually hoisted the variables with let at the top of the function block as a working solution (as described in jmar777's answer) still an interesting question to see the various approaches, so I'll leave the question open for now.
Coming back to this question a few years later a far simpler answer has occurred to me, I don’t see in retrospect why I was interested in a small try/catch pair and then performing more logic outside of it when I could simply perform all the logic and return inside the try statement.
Taking the example from the question and applying that structure it would be:
async function () {
try {
const result = await get_session()
// Do what needs to be done and then:
return result
} catch (err) {
console.log(`This block should catch any
instantiation errors.`)
return false
}
}
If you need to access anything from the try block in the catch block raise it in an error. There may be a reason I needed to move out of the try scope when I asked this question, but I can’t see a scenario that would necessitate it looking back. This solution wouldn’t work if you were to use try/catch/finally and return in finally. But I don’t think I’ve come across that pattern much at all in the wild.