Error boundaries help catch errors in parts of your app so the whole page does not break. They show a fallback UI instead of a blank or broken screen.
Client-side error boundaries in NextJS
Start learning this pattern below
Jump into concepts and practice - no test required
import React from 'react'; class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } render() { if (this.state.hasError) { return <div>Something went wrong.</div>; } return this.props.children; } }
Next.js uses React, so error boundaries follow React patterns.
Client-side error boundaries catch errors during rendering, lifecycle methods, and constructors of child components.
import React from 'react'; class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } render() { if (this.state.hasError) { return <div>Oops! Something went wrong.</div>; } return this.props.children; } }
import React from 'react'; class ErrorBoundary extends React.Component { state = { error: null }; static getDerivedStateFromError(err) { return { error: err }; } render() { if (this.state.error) { return <div role="alert">Error: {this.state.error.message}</div>; } return this.props.children; } }
This example shows a component that throws an error inside an error boundary. Instead of crashing the whole app, it shows a friendly error message in red.
import React from 'react'; class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } render() { if (this.state.hasError) { return <div role="alert" style={{ color: 'red' }}>Something went wrong.</div>; } return this.props.children; } } function BuggyComponent() { throw new Error('Bug!'); } export default function App() { return ( <main> <h1>My Next.js App</h1> <ErrorBoundary> <BuggyComponent /> </ErrorBoundary> </main> ); }
React error boundaries are class components using static getDerivedStateFromError() and optionally componentDidCatch(). Next.js follows the same patterns.
Client-side error boundaries do not catch errors in event handlers or asynchronous code.
Use fallback UI that is accessible and clear to users.
Error boundaries catch errors in parts of your UI to prevent full app crashes.
They show fallback UI so users see a friendly message instead of a broken screen.
In Next.js, you can create client-side error boundaries using React class components.
Practice
Solution
Step 1: Understand error boundaries role
Error boundaries catch errors in parts of the UI to prevent the entire app from crashing.Step 2: Identify their main effect
They show a fallback UI so users see a friendly message instead of a broken screen.Final Answer:
To catch errors in UI components and show a fallback UI instead of crashing the whole app -> Option AQuick Check:
Error boundaries catch UI errors = C [OK]
- Confusing error boundaries with server-side features
- Thinking they handle backend or database errors
- Assuming they improve performance directly
Solution
Step 1: Identify hook-based error boundary pattern
Client-side error boundaries in Next.js use try/catch inside functional components to catch errors during rendering.Step 2: Check each option
function ErrorBoundary({ children }) { try { return children; } catch { return ; } } uses try/catch inside a function component returning children or fallback UI, which is correct.Final Answer:
function ErrorBoundary({ children }) { try { return children; } catch { return <Fallback />; } } -> Option AQuick Check:
Try/catch in function component = A [OK]
- Using class components instead of functional components
- Not using try/catch to catch errors
- Returning children without error handling
function ErrorBoundary({ children }) {
try {
return children;
} catch {
return <div>Error occurred</div>;
}
}
function BuggyComponent() {
throw new Error('Bug!');
}
export default function App() {
return (
<ErrorBoundary>
<BuggyComponent />
</ErrorBoundary>
);
}What will be rendered on the page?
Solution
Step 1: Understand error throwing in BuggyComponent
BuggyComponent throws an error immediately when rendered.Step 2: Check ErrorBoundary behavior
ErrorBoundary tries to render children inside try block; error triggers catch block returning fallback UI <div>Error occurred</div>.Final Answer:
<div>Error occurred</div> -> Option BQuick Check:
Error caught, fallback shown = D [OK]
- Expecting the app to crash instead of showing fallback
- Thinking children render despite error
- Confusing output with component name
function ErrorBoundary({ children }) {
try {
return children;
} catch (error) {
console.log(error);
}
}
export default function App() {
return (
<ErrorBoundary>
<div>Hello</div>
</ErrorBoundary>
);
}What issue will occur when an error happens inside children?
Solution
Step 1: Analyze catch block behavior
The catch block logs the error but does not return any UI.Step 2: Understand React rendering rules
Without a return in catch, the component returns undefined, rendering nothing on error.Final Answer:
No fallback UI is returned, so the component renders nothing -> Option DQuick Check:
Missing return in catch = renders nothing [OK]
- Forgetting to return fallback UI in catch
- Assuming logging error is enough
- Expecting children to render after error
Solution
Step 1: Check error catching and logging
function ErrorBoundary({ children }) { try { return children; } catch (error) { console.error(error); returnSomething went wrong.; } } catches error, logs it with console.error, then returns fallback UI.Step 2: Verify fallback UI return
function ErrorBoundary({ children }) { try { return children; } catch (error) { console.error(error); returnSomething went wrong.; } } returns fallback UI after logging, ensuring user sees message and error is logged.Final Answer:
function ErrorBoundary({ children }) { try { return children; } catch (error) { console.error(error); return <div>Something went wrong.</div>; } } -> Option CQuick Check:
Error caught, logged, fallback returned = A [OK]
- Not logging the error before fallback
- Not returning fallback UI after catching error
- Logging without returning fallback UI
