Question 2
Errors, retries, and UX
How do you handle network failures, retries, and error states in a way that provides a good user experience?
Answer outline
Not every failure deserves the same response — the key is classifying errors and reacting appropriately at each layer.
- 1.Classify errors at the boundary — map raw
URLErrorand HTTP status codes into typed app-level categories (transient, client, server, decoding) so feature code never has to inspect them directly. - 2.Retry selectively — transient failures like timeouts and connectivity loss are worth retrying with exponential backoff; 400s and decoding errors should fail fast.
- 3.Check idempotency before retrying writes — retrying a GET is safe; retrying a POST that creates data may not be. Use client-generated request IDs to let the server detect duplicates.
- 4.Degrade gracefully in the UI — show cached data when possible, offer a manual retry, and avoid blocking the whole screen for a failure that only affects one component.
Principles
- Keep retry and error-handling logic in one place, not scattered across features.
- Errors should show a meaningful message to the user, not just a raw status code.