Elegantly Handling Reject on `await`ed Javascript Promise

Question

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.

Answer 1

You may have a misunderstanding regarding the benefits of using const. Assigning a value using a const declaration doesn't make that value immutable, it simply means that the value of that constant can't be changed or redeclared:

The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, just that the variable identifier cannot be reassigned. For instance, in case the content is an object, this means the object itself can still be altered. (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const)

In your example, you're probably best off manually hoisting your result binding outside of the try/catch:

async function () {
  let result;

  try {
    result = await get_session()
  } catch (err) {
    console.log(`This block should catch any
      instantiation errors.`)
  }

  // do whatever else you need with result here...
}

An alternative would be to restructure the code such that you don't need to rely on a try/catch at all. For example:

async function () {
  const result = await get_session().catch(someRejectionHandler); 

  // do whatever else you need with result here...
}

Just be aware that your downstream code needs to gracefully handle the case where get_session() was rejected, and result isn't initialized based on a successful response. This is no different than in your initial example, but perhaps not quite as obvious when scanning the code.