-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More informative error types #526
Comments
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:
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 |
@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 |
@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 |
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? |
Sadly no. |
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 |
@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:
|
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 |
This comment was marked as duplicate.
This comment was marked as duplicate.
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 |
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 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:
Unfortunately I cannot distinguish CSP/CORS-related errors from actual network errors using this code but it’s as close as I can get. |
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?The text was updated successfully, but these errors were encountered: