More informative error types

[jakearchibald]

Just had a chat with an internal team requesting more detailed errors, so they can tell the difference between a timeout / connection failure / bad params etc etc.

Given that we're going to be introducing AbortError, should we revisit other errors?

[annevk]

To some extent there's #352.

And then there's the question of what exactly resource timing (I believe that's the one, not sure) exposes, when, and how many user agents have decided that's an acceptable level of exposure.

If we have those details, we could consider it. (Then there's the problem of potential compatibility fallout, that we can only measure through telemetry (or maybe not) or we add information to TypeError instances which is rather hackish.)

[Noitidart]

This is also an issue in react-native because they use what-wg fetch. Is there a way to differentiate between timeout or offline? Currently both situation throw the same error which from my memory is something like "NetworkRequest failed".

https://stackoverflow.com/q/48847068/1828637

[mfalken]

A way forward may be to make a list of desired error types and see which ones are OK to expose cross-origin or not. Here's a strawman:

• "API error" (gave something that's not a Request or a URL to fetch())
• "network error" (something at the TCP/IP layer caused us to fail to fetch
• "abort error" (the user closed the tab or clicked stop or something like that)
• "timeout error" (the browser timed out the request (I'm not sure this really happens for fetch()))
• "offline error" (this is a subset of network error when the browser knows it's offline)

I guess we already have the name AbortError taken with the new abortable fetch thing.

[annevk]

Most of those are probably reasonable (assuming "offline error" matches navigator.onLine). @domenic is someone still pursuing ways to add custom data to errors somehow in TC39? It seems hard to switch away from TypeError here.

[annevk]

@mattto per whatwg/xhr#96 WebKit at least has a network timeout. I suspect that applies to all browsers to some extent.

[jakearchibald]

@annevk why would it be hard to switch from TypeError? Do we think folks are looking at the type currently?

[annevk]

@jakearchibald I'd expect so; we certainly do so throughout the test suite. I know it's not common practice, but it's also rather hard to guarantee that nobody is doing it.

[jakearchibald]

@mattto is there any way we can get data on that?

Alternatively, we could give priority to FetchObserver and put the data there.

[mfalken]

I imagine it'd be hard to get data on that. There's no clear API entry point we could add a UseCounter for. We could probably do a search on HTTPArchive to try to find sites that do this. What would the script code look like? Something like this?
fetch(...).catch(err => { err instanceof TypeError; })

cc @yutakahirano

[domenic]

@domenic is someone still pursuing ways to add custom data to errors somehow in TC39?

Sadly no.