no-return-await must be aware of try/catch/finally

no-return-await currently doesn’t consider if the return statement is inside a try block. In this case, the presence of await does meter.

Consider this:

function asyncLog() {
  return new Promise((resolve) => {
    setTimeout(() => {
      console.log('first log');
      resolve(true);
    }, 1000);
  });
}

async function foo() {
  try {
    return await asyncLog();
    // I really need this await, but no-return-await is complaining about it :(
  } finally {
    console.log('second log');
  }
}

foo();
// first log
// second log


async function bar() {
  try {
    return asyncLog();
  } finally {
    console.log('second log');
  }
}

bar();
// second log
// first log


async function baz() {
  try {
    return asyncLog();
  } catch (error) {
    // if asyncLog() rejects, error will be swallowed because I missed await :(
  }
}

[not-an-aardvark]

The intention of the no-return-await rule is to flag unnecessary return await statements where await could be removed without observably changing the behavior of the code*. When return await is used within a try statement, this is not the case.

---

*aside from the fact that the Promise will fulfill one tick sooner

[daltones]

The problem is that the warning message of this rule is “Redundant use of await on a return value”.

The term “Redundant” is in fact incorrect in these try cases.