Re: [fetch] Aborting a fetch (#27)

> Anyway, I'd rather get consensus on the feature design before bikeshedding naming.

Sure, I won't bring up naming again.

> here's the catch: the code that is expecting a value will never be executed once the promise is canceled. It will be silently resolved and ignored for that "predefined time-lapse" that will be resolved and never executed.

The problem I see is that the next step in the chain might expect something, for example:
```js
fetch(url)
.then(r => r.json())
.cancel() //cancel, the above line resolves to undefined
.then(json => json.something) //this line rejects with an error, because json is undefined
```
The same applies to rejecting with undefined:
```js
fetch(url)
.cancel()
.catch(logErrorToSomewhere);
```
This will log a lot of `undefined` to a service that is interested in errors on the frontend. With a lot of canceling (for example a search field that does autocomplete) there will be a lot of noise in the catch. To work around this you would need to check for undefined in the catch handlers, which means you need an if check in (potentially) all your catch handlers.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-87652776