API failures should normally be represented as application state so [React](/courses/reactjs) can show users what happened and provide an appropriate recovery action. An API request can fail for many reasons: ```text No network connection Server error Unauthorized request Resource not found Timeout or cancellation Invalid response Validation failure ``` ### Basic Fetch Error Handling ```jsx import { useEffect, useState } from "react"; function UserProfile() { const [user, setUser] = useState(null); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { async function loadUser() { try { setLoading(true); setError(null); const response = await fetch("/api/user"); if (!response.ok) { throw new Error( `Request failed: ${response.status}` ); } const data = await response.json(); setUser(data); } catch (error) { setError(error.message); } finally { setLoading(false); } } loadUser(); }, []); if (loading) { return

Loading profile...

; } if (error) { return (

Unable to load profile

{error}

); } return ; } ``` ### Fetch Requires HTTP Status Checking A common mistake is assuming this enters `catch` for every HTTP error: ```javascript await fetch("/api/users"); ``` Fetch can resolve successfully at the Promise level even when the server responds with statuses such as: ```text 404 500 ``` Therefore check: ```javascript if (!response.ok) { throw new Error(...); } ``` ### Different Errors May Need Different UI Instead of showing the same message for everything, the application may distinguish errors. Conceptually: ```text 401 → Please sign in 403 → You do not have permission 404 → User not found 500 → Something went wrong on our server Network failure → Check your internet connection ``` ### Retry UI Transient failures should often provide a retry option: ```jsx function ErrorState({ onRetry }) { return (

We couldn't load the data.

); } ``` The important point is that fallback UI should help users recover rather than merely expose a technical stack trace. ### Keep Existing Data During Background Failure When Appropriate Suppose cached data is already displayed and a background refresh fails. Instead of replacing everything with: ```text ERROR ``` a better experience may be: ```text Keep existing data visible + show "Could not refresh" + allow retry ``` Whether this is appropriate depends on how stale data affects the feature. ### Do Not Expose Sensitive Backend Details Avoid displaying raw production errors such as: ```text MongoServerError... SQL connection credentials... Internal file paths... Stack traces... ``` Users generally need a safe, actionable message, while detailed diagnostics belong in application logs or monitoring systems. ### Error Boundary vs API Error UI An API returning: ```text 500 Internal Server Error ``` does not necessarily mean the [React](/courses/reactjs) component itself has crashed. The component can still render normally and display: ```jsx ``` Therefore API failure state should normally be handled explicitly instead of relying on Error Boundaries. ### Interview-Ready Answer API errors should normally be caught where the request is made and represented through loading, error, and success state. With Fetch, HTTP status must be checked explicitly using `response.ok`. Good fallback UI explains the problem safely, distinguishes meaningful error types when useful, and provides recovery actions such as retry without exposing sensitive backend details.