Robust network error handling strategy
differentiated error handling.
classify errors as 4xx, 5xx, or connectivity; retry transient failures with backoff, surface actionable messages, and check NetInfo.
one generic catch that retries everything, including 400s.
What's really being asked
Whether you treat network failures as distinct categories with different remedies, and whether you centralize handling instead of scattering try/catch everywhere.
The full answer
Classify failures. A 4xx means the request itself is wrong, so retrying is pointless; handle 401 by refreshing the token, 403 by surfacing a permissions message, 404 by an empty state, and 422 by field-level validation feedback. A 5xx is typically transient, so retry with exponential backoff plus jitter, capped at a few attempts, ideally only for idempotent requests. A connectivity failure, detectable with NetInfo, should not be confused with a server error; queue the action or show an offline banner and retry on reconnect. Centralize all of this in an Axios response interceptor or a fetch wrapper so every call benefits, log errors to a service like Sentry, and present human-readable messages.
The mistakes people make
A single generic catch that retries every error including 400s, retrying non-idempotent POSTs blindly, showing raw error objects, or treating a timeout identically to a 500. Ignoring token-refresh flows for 401 is a frequent gap.
What usually comes next
Why add jitter to backoff? Which methods are safe to retry automatically? How do you avoid an infinite refresh loop on repeated 401s? How does a circuit breaker fit?
A concrete example
A response interceptor inspects the error: on 401 it attempts a single token refresh and replays the request; on 503 it retries after delays of roughly 1s, 2s, and 4s with random jitter, then gives up and surfaces 'Service unavailable, try again'; on a network error from NetInfo being offline it queues the mutation and shows an offline banner, replaying when connectivity returns. A 400 is never retried; the validation message is shown immediately.
Interview question
Why should an automatic retry-with-backoff strategy generally exclude HTTP 4xx responses?
- a.4xx responses are always returned faster than the retry timer can fire
- b.4xx errors are network-layer failures that backoff cannot influence
- c.Retrying 4xx requests violates the HTTP specification and is rejected by servers
- d.4xx indicates a flawed request, so repeating it unchanged will keep failingCorrect
Why? this is the answer
A 4xx means the client request is invalid, so retrying it without change yields the same error; only transient 5xx or connectivity issues benefit from backoff. 4xx are application-layer responses, not network failures, so that option is wrong.
Just read this? Test yourself on what you have been reading.
Read the original → oneuptime.com
- #error-handling
- #retry
- #exponential-backoff
- #networking
- #netinfo
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
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. Open roles that interview on error-handling — each one lists the topics its interview covers.
See open roles