How would you modify fetch to handle HTTP error statuses?
awareness that fetch resolves on HTTP errors and needs manual status checking.
verify response.ok in then and throw if false, then catch network failures separately.
What's really being asked
This question checks whether you know the exact rejection semantics of the fetch API. Many developers assume that a 404 or 500 will trigger the catch path, but the specification defines rejection only for network-level failures such as no connectivity, DNS errors, or CORS violations. The interviewer wants to see that you explicitly inspect the Response object before consuming the body, and that you understand the difference between transport failures and application-level error statuses.
The full answer
First, state clearly that fetch resolves for any HTTP status, including 4xx and 5xx, and only rejects on network errors. Second, describe chaining a then block that checks response.ok, which is true only for statuses in the 200-299 range. Third, explain that if response.ok is false, you should throw a custom error so the single catch block can handle both network failures and HTTP errors uniformly. Fourth, mention that you might also read response.status or response.statusText to enrich the error message, and that you should avoid parsing the body until you have confirmed the response is healthy.
The mistakes people make
A red flag is saying that fetch rejects on 404 or 500. Another mistake is calling response.json or response.text before checking response.ok, which can cause parsing errors on HTML error pages. Some candidates suggest checking only response.status equals 200, which is too narrow because 201 Created or 204 No Content are also successful. Others forget to throw and instead return the raw response, forcing every consumer to check status manually. Finally, swallowing errors by returning the response object silently when ok is false shows a lack of defensive coding.
What usually comes next
The interviewer may ask how you would handle non-JSON error bodies, how to abort a request with AbortController, or how to retry failed requests with exponential backoff. They might also ask about TypeScript typing for the error payload, how to distinguish transient network errors from permanent HTTP errors in logging, or how to wrap fetch in a reusable HTTP client that centralizes this logic.
A concrete example
You might write a fetch call that chains a then handler where you first check if response.ok is false and if so throw a new error including the status code, otherwise return response.json. A following then receives the parsed data, and a catch at the end receives both network failures and the HTTP errors you threw. In this pattern, a 404 causes the thrown error to propagate into the catch block, while a disconnected Wi-Fi also lands in catch, giving you one place to handle all failure modes and keeping your success path clean.
Interview question
When using fetch, how can you ensure both network failures and HTTP 404 errors are handled by the same catch block?
- a.Attach a second catch block right after fetch to capture 4xx and 5xx status codes
- b.Check response.ok in the then handler and throw an error if false, before parsing the bodyCorrect
- c.Immediately call response.json() and throw if the parsed result lacks expected data fields
- d.Check if response.status equals 200 and throw if not, then return response.json()
Why? this is the answer
fetch resolves for HTTP error statuses, so you must inspect response.ok and throw manually to reach the catch block. A second catch block is ineffective because 4xx and 5xx responses do not trigger rejection.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles