More informative error types
jakearchibald opened this issue · comments
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?
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.)
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".
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.
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.
@mattto per whatwg/xhr#96 WebKit at least has a network timeout. I suspect that applies to all browsers to some extent.
@annevk why would it be hard to switch from TypeError? Do we think folks are looking at the type currently?
@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.
@mattto is there any way we can get data on that?
Alternatively, we could give priority to FetchObserver and put the data there.
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; })
@domenic is someone still pursuing ways to add custom data to errors somehow in TC39?
Sadly no.
fetch(...).catch(err => { err instanceof TypeError; })
I feel it very strange because currently TypeError is the only error type fetch throws (except for AbortError, right, but it's still not very popular I guess...). The only usecase I can image except for testing is checking whether the error is thrown by fetch, together with statements that may throw errors other than TypeError, so that should be more complicated. Also, we need to care about .name, I think.
@yutakahirano agreed. This is why I was surprised @annevk said it'd be difficult to switch. Although it seems difficult/impossible to know for sure.
This discussion aligns pretty closely with the Network Error Logging spec, which would allow the user agent to upload reports about these kinds of failures to the server owner. NEL currently defines a list of error types (a glorified string enum), but if that list were part of fetch, we wouldn't have to.
What's the status of this? This would be very helpful to distinguish being offline from real errors - to help catch bad configurations, bugs in the service worker, etc.
Nobody is working on this, though it seems like necessary infrastructure, e.g., for Network Error Logging. If someone wants to take this on, there are roughly three parts here:
- Identify all the places where we create a "network error" today, annotate them with a private slot regarding the type of error and ensure that annotation makes it all the way to the caller. (E.g., there might be places where we return a new network error at some point as currently there is no distinction.) This should not be too hard, although when we get to the HTTP layer there might be some difficulty in identifying all the appropriate types. (Perhaps Network Error Logging can help.)
- Figure out what from 1 we can reasonably expose to JavaScript, without giving attackers more information than they have today.
- Figure out out how to expose what remains in 2 to JavaScript.
I still think a fetch observer is the right way to expose it, but yeah, steps 1 & 2 can be done before we decide on that.
Hi all, I am one of the maintainers of Ky, which is a fetch-based library for HTTP requests. We would like the ability to differentiate fetch errors from other types of errors, including implementation errors from our users. This currently seems to require inspecting error.message, which is full of problems. Among other things, different browsers throw errors with different messages for the same situation. It's very messy. We would very much appreciate any improvements that could be made here.
Any news?
There is now https://github.com/sindresorhus/is-network-error, a bandaid solution that matches on the returned error strings, which all implementations handle differently.
This is probably not easily fixable from a spec perspective because code in the wild relies on the existing TypeError class, so one can't just introduce a NetworkError class now.
Unfortunately I missed the nuance in the more recent replies that are not asking for more granularity but instead are asking for distinguishing the exception when you are further away from the caller. I suppose one thing we could do is try to standardize the message value. Looking at https://github.com/sindresorhus/is-network-error/blob/main/index.js Chromium's "Failed to fetch" seems pretty reasonable.
That's not a great solution, but it's an improvement.
I'm not entirely sure what a great solution would look like.
I came across this issue today and had to come up with a best-effort approach. I tweeted about it:
I can't find a reliable way to detect retryable connection/network errors using fetch across @nodejs, @bunjavascript, @GoogleChrome and other platform. It's really unfortunate that the spec authors landed on throwing TypeError for pretty much anything that can go wrong. This includes CORS and CSP violations on the browser which are not retryable and those errors are opaque to JS code. DOMException is already used by AbortSignal and could have been a good choice since it's
.nameproperty reflects an error code. An explicit FetchError would have been even better still.
Playground link
Unfortunately I cannot distinguish CSP/CORS-related errors from actual network errors using this code but it’s as close as I can get.