Implement error handling when using the Fetch API

 https://web.dev/articles/fetch-api-error-handling

Note that the following code examples use top-level await (browser support) because this feature can simplify your code.

When the Fetch API throws errors

This example uses a try/catch block statement to catch any errors thrown within the try block. For example, if the Fetch API cannot fetch the specified resource, then an error is thrown. Within a catch block like this, take care to provide a meaningful user experience. If a spinner, a common user interface that represents some sort of progress, is shown to the user, then you could take the following actions within a catch block:

1. Remove the spinner from the page.
2. Provide helpful messaging that explains what went wrong, and what options the user can take.
3. Based on the available options, present a "Try again" button to the user.
4. Behind the scenes, send the details of the error to your error-tracking service, or to the back-end. This action logs the error so it can be diagnosed at a later stage.

try {
  const response = await fetch('https://website');
} catch (error) {
  // TypeError: Failed to fetch
  console.log('There was an error', error);
}

At a later stage, while you diagnose the error that you logged, you can write a test case to catch such an error before your users are aware something is wrong. Depending on the error, the test could be a unit, integration, or acceptance test.

When the network status code represents an error

This code example makes a request to an HTTP testing service that always responds with the HTTP status code 429 Too Many Requests. Interestingly, the response does not reach the catch block. A 404 status, amongst certain other status codes, does not return a network error but instead resolves normally.

To check that the HTTP status code was successful, you can use any of the following options:

• Use the Response.ok property to determine whether the status code was in the range from 200 to 299.
• Use the Response.status property to determine whether the response was successful.
• Use any other metadata, such as Response.headers, to assess whether the response was successful.

try {
  const response = await fetch('https://httpbin.org/status/429');
  // network error in the 4xx–5xx range
  if (!response.ok) {
    throw new Error(`${response.status} ${response.statusText}`);
  }
  // use response here if we didn't throw above
  doSomethingWith(response);
} catch (error) {
  console.log(error);
}

The best practice is to work with people in your organization and team to understand potential HTTP response status codes. Backend developers, developer operations, and service engineers can sometimes provide unique insight into possible edge cases that you might not anticipate.

Note: Note from the author: I was recently scrolling through an infinite scrolling list on a website, trying to quickly reach the bottom. Eventually, the page seemed to break with no helpful messaging. Upon inspecting the network request via DevTools, it became clear that the HTTP status code error 429 Too Many Requests was returned. In an ideal scenario, such internal errors are surfaced to the web page interface.

When there is an error parsing the network response

This code example demonstrates another type of error that can arise with parsing a response body. The Response interface offers convenient methods to parse different types of data, such as text or JSON. In the following code, a network request is made to an HTTP testing service that returns an HTML string as the response body. However, an attempt is made to parse the response body as JSON, throwing an error.

let json;

try {
  const response = await fetch('https://httpbin.org/html');
  json = await response.json();
} catch (error) {
  if (error instanceof SyntaxError) {
    // Unexpected token < in JSON
    console.log('There was a SyntaxError', error);
  } else {
    console.log('There was an error', error);
  }
}

if (json) {
  console.log('Use the JSON here!', json);
}

You must prepare your code to take in a variety of response formats, and verify that an unexpected response doesn't break the web page for the user.

Consider the following scenario: You have a remote resource that returns a valid JSON response, and it is parsed successfully with the Response.json() method. It may happen that the service goes down. Once down, a 500 Internal Server Error is returned. If appropriate error-handling techniques are not used during the parsing of JSON, this could break the page for the user because an unhandled error is thrown.

When the network request must be canceled before it completes

This code example uses an AbortController to cancel an in-flight request. An in-flight request is a network request that has started but has not completed.

The scenarios where you may need to cancel an in-flight request can vary, but it ultimately depends on your use case and environment. The following code demonstrates how to pass an AbortSignal to the Fetch API. The AbortSignal is attached to an AbortController, and the AbortController includes an abort() method, which signifies to the browser that the network request should be canceled.

const controller = new AbortController();
const signal = controller.signal;

// Cancel the fetch request in 500ms
setTimeout(() => controller.abort(), 500);

try {
  const url = 'https://httpbin.org/delay/1';
  const response = await fetch(url, { signal });
  console.log(response);
} catch (error) {
  // DOMException: The user aborted a request.
  console.log('Error: ', error)
}