Warum return await in JS nicht immer schlecht ist, sondern im Gegenteil sogar richtig

Manche JS-Entwickler tun schlau und behaupten, dass man statt:

return await someService.doSomething();

lieber schreiben sollte:

return someService.doSomething();

Nach dem Motto: Wenn eine async-Funktion in ihrem return ein Promise zurückgibt, wird ja sowieso das Ergebnis der Auflösung dieses Promises zum eigentlichen Rückgabewert. Promises werden also quasi rekursiv "entpackt".

Das klingt erstmal plausibel, aber es gibt ein ziemlich ernstes Problem dabei. Schaut euch mal diesen Code an:

// Technisch gibt diese Funktion ein Promise zurück,
// wirft aber in Wirklichkeit einen Fehler
async function fun1() {
  throw new Error('Hi from Famabara!');
}

(async () => {
  try {
    return await fun1();
  } catch (err) {
    console.log('Error catched!', err);
  }
})();

Hier ist alles in Ordnung, der Fehler wird im catch Block abgefangen. Schreibt man es aber so:

async function fun1() {
  throw new Error('Hi from Famabara!');
}

try {
  (async () => {
    try {
      return fun1();
    } catch (err) {
      console.log('Error catched!', err);
    }  
  })();
} catch (err) {
  console.log('Error catched!', err);
}

dann fängt keiner der beiden catch Blöcke den Fehler ab! Das ist ein wirklich heftiger Nachteil. Der Fehler lässt sich dann gar nicht mehr abfangen - man müsste zwingend catch() direkt auf dem Promise aufrufen, wenn man kein await verwendet.

Kurz gesagt: Die Empfehlung, kein return await zu schreiben, ist eine sehr schlechte Empfehlung. Geradezu schädlich.