Describe error.js.
An error file allows you to handle unexpected runtime errors and display fallback UI.
- 1
It is defined at a route level
- 2
Loading UI components do not accept any parameters.
- 3
It receives error object, and reset as props
- 1
Runtime Errors in Client Components: Errors that occur within the browser after the page has loaded.
- 2
Runtime Errors in Server Components: If a Server Component throws an error during rendering on the server, Next.js will forward that error to the nearest error.js file.
- 3
Errors in page.js: Since error.js wraps the page.js file of the same route segment, it effectively catches any blowups within that page.
- 4
Data Fetching Errors: If an async Server Component fails to fetch data (e.g., fetch throws an error), the UI will swap to the error boundary.
- 1
Errors in the same-level layout.js: This is the most common point of confusion. Because layout.js sits above error.js in the component tree, the error boundary cannot see errors happening in its sibling layout. To catch those, you need an error.js in the parent directory.?
- 2
Errors in global-error.js territory: Specifically, errors in the root app/layout.js are not caught by a standard app/error.js. You must use a global-error.js file in the root to handle those.
- 3
404 Not Found Errors: These are handled by not-found.js, not error.js.
- 4
Syntax Errors: Errors that prevent the code from compiling or building (found during npm run build) will stop the process entirely before the error boundary ever has a chance to run.
- 5
Server Actions / API Route Errors: While you can use try/catch inside a Server Action to trigger an error state, error.js doesn't automatically intercept a failed POST request unless that failure causes the component rendering to throw.
Scenario Questions
- 1
Imagine you have a product detail page in Next.js that occasionally fails to fetch data from a third-party API, crashing the page. How would you set up an error.js file in that route to show a friendly error message and let the user click a 'Try Again' button without reloading the whole app?
- 2
You just added an error.js file to your /dashboard route, but when you run the app, you get a console error saying something about React hooks or client-side rendering. What did you likely forget to add at the top of your error.js file, and why is that required?
- 1
We have a dashboard layout with a sidebar and a main content area. If an error occurs inside the layout.js file itself, our error.js file in the same folder isn't catching it, and the whole app crashes. Why is this happening, and how would you restructure your files to catch layout-level errors?
- 2
You're debugging a Next.js app where a nested route /dashboard/settings throws an error. There is an error.js in /dashboard and another one in /dashboard/settings. Which error boundary will catch the error, and how would you programmatically trigger a retry of just the settings component?
- 1
We are building a large-scale e-commerce site using Next.js App Router. We need to ensure that any runtime error caught by our error.js boundaries is automatically logged to Sentry with the original stack trace, while still showing a localized, sanitized message to the user. How would you architect this error-reporting boundary, especially considering that server-side errors might contain sensitive database details?
- 2
In a complex dashboard with multiple nested parallel routes (e.g., @analytics and @feed), a crash in @feed shouldn't bring down the entire page or the @analytics panel. How would you strategically place your error.js files to isolate these failures, and what are the UX tradeoffs of granular vs. page-level error boundaries?
- 1
We are migrating a legacy Pages Router application with a custom _error.js to the App Router. The legacy app relied heavily on global state and custom redirect logic during rendering errors. How would you design a progressive migration strategy for error handling that maintains consistent telemetry and user experience across both routers during the transition?
- 2
At scale, network flakiness can cause transient chunk loading errors (e.g., 'Failed to fetch dynamically imported module'). How would you design a resilient, application-wide error recovery strategy using global-error.js and custom error.js boundaries to automatically recover from these deployment-skew/chunk errors without frustrating the user?
Follow-up Questions
- ❓How does global-error.js differ from a standard error.js in terms of placement and rendering behavior?
- ❓What happens to the state of parent layouts when a nested error.js boundary is triggered and then reset?
- ❓How do you handle server-side errors differently from client-side errors inside the error object passed to error.js?