Re: [heycam/webidl] Proposal: DOMException.ignoreAborts(promise) (#933)

I think this is a great idea, though I realized after looking at some places in our codebase where we’re doing “isAbortError” checks that it seems like it might be a more niche thing than I initially supposed (or maybe we’re just weird) and that it may not be helpful in our case.

It seemed like the most common places where we have these checks is in async functions where control flow _should_ move to the catch block if an abort occurs. If I’m not mistaken, if we tried to leverage this API, we’d end up having to move the error handling that occurs within these catch blocks elsewhere in each such case — and it might end up being a net loss for removing boilerplate / improving clarity.

```js
async butterBiscuits({ signal }) {
  try {
    this.biscuits.butter = await fetch('https://butternet/the-good-stuff?lots', { signal });
  } catch (err) {
    if (!isAbortError(err)) {
      alerts.push('a TERRIBLE thing happened');
      throw err;
    }
  }
}
```

Note that if the fetch here aborts, we _wouldn’t_ want `this.biscuits.butter` to be set to `undefined`. Sometimes there are sequentially or simultaneously awaited-things; sometimes there’s more complex handling based on e.g. HTTP status codes, etc. But in all cases I found, we’d never want `DOMException.ignoreAborts(aSpecificPromiseWithinTheOverallLogic)` inside the try block portion — it’s only the “top level” async logic that wants to ignore aborts.

Is there a pattern I’m missing where `ignoreAborts` would provide a benefit for cases like that? (Of course, there doesn’t have to be; it could be that this API is tailored specifically for cases like the initial example where you want to continue after a “child” promise gets aborted, which is still useful.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/933#issuecomment-719653350