Why isn't error set for 4XX/5XX http status codes?

[aloukissas]

This is still counter-intuitive - I always have to write this extra code in my fetcher function to check e.g. if (res.ok).

How do people use this? Am I missing something?

[sergiodxa]

This is not a SWR thing but a Fetch API issue, the API doesn’t throw an error when an HTTP 4xx/5xx error is thrown, so you need to do it, remember SWR can work with anything as a fetcher function.

What I usually do is to create a generic wrapper of fetch to check the status and throw an error.

[aloukissas]

Thanks - I get this part. My main question is more of a design choice for swr. If for most common cases (4xx/5xx) the error isn't set, what's the point in including it in all the examples?

[shuding]

Mainly because SWR doesn't know about your fetcher — it can be a native fetch, or any function that loads the data. And of course, as a caller of fetcher() it only know that either the data is returned, or an error is thrown. It can't know what the status code is. The best practice is still to define your own fetcher.

[pke]

Not related to swr, since its API agnostic but worth explaining maybe.

While it might seem counter intuitive I think the fetch API handles HTTP error codes correct. In certain contexts a 401 or 404 might be not treated as errors but could just trigger other application flow.
Take 401 when trying to authenticate. Your app most certainly will not just throw an error to the user but redirect/show a login interface to (re)validate the user.
Similar 404 could just mean, a certain resource is not available and that does not mean your app has to throw this error to the users face. Instead it could just trigger a different render path. A 404 response for a certain image might be technically an error but would not render the app useless in the context it is.

And thats the reason the fetch API is defined to reject only for network interface errors. Meaning a request or response did not reach its destination. If a request could be sent and a response of whatever nature was received this is considered the promise fulfilled.

[shuding]

I agree with what @pke said. Take this API for an example:

const { error, data } = useSWR('/api/teams/my-team', () => {
  const res = await fetch('/api/teams/my-team')

  if (res.status === 401) throw new Error('Not authorized')
  if (res.status === 404) return { team: null }
  if (res.status === 200) return { team: await res.json() }
  
  throw new Error('An error occurred')
})

if (error) // we can redirect to /login or show an error page

// render the team or "team not found" text

Basically, it's more like the business logic: if we want to continue with the render flow, we return. Otherwise if we want to abort, we throw. It's not 100% associated with the status code.