I disagree that the fix is to catch and ignore the error. The fetch handling logic should be catching the errors and reporting them somewhere (ex. Sentry or the UI). In a production app where you report and log errors this "issue" doesn't manifest.
I usually catch rejections then turn them into a resolution as an object with an 'errno' property. That way, your handler always gets called, rejections are never generated up to the top level, and you can move the error handling into your consumer very easyily.
const thing = await fn();
if (thing?.errno) {
//handle error
return;
}
// handle result
Maybe I spent too much time writing C code. There are very few times when I actually want a rejection to take an entirely different path through my code, and this feels like the correct way to write it.
The error isn't ignored. The parent function will still reject if it's unable to complete the operation (with the fetch error, if fetch was the cause of the error).
I didn't say it's globally ignored (I understand how promises work :)), I said what you did in the code sample adds a catch that ignores the error (it's an empty catch). In real code that wouldn't be empty though, it should have error reporting logic or something to handle that situation in the UI. Once you do that it's not a "hack" anymore, it's just reasonable error handling.
