Error boundaries with catchError
Error boundaries contain failures during rendering. Use `catchError` for component-level boundaries, or the `error.js` file convention for route-level boundaries.
Next.js App Router · all subjects
error handling & boundaries
10 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Error Boundary definition and implementation
An Error Boundary is a React component that catches JavaScript errors in its child component tree and displays a fallback UI. In Next.js, create an error.js file to automatically wrap a route segment in an error boundary.
Not Found special component
Not Found is a special component shown when a route doesn't exist or when the notFound() function is called. It is created by adding a not-found.js file to your app directory.
next-code-frame Rust crate for error reporting
next-code-frame is a Rust crate that provides fast, scalable code frame rendering for Next.js error reporting. It handles arbitrarily large files efficiently, gracefully scrolls long lines to keep error positions visible, and provides syntax highlighting using a language-agnostic regex tokenizer.
next-code-frame CLI usage for error positions
The next-code-frame binary accepts a filename and start/end positions using 1-indexed line:column notation. Usage examples: 'cargo run -p next-code-frame --bin code_frame -- src/app.tsx 10:5' highlights a single position, 'cargo run -p next-code-frame --bin code_frame -- src/app.tsx 10:5 10:20' highlights a range, and 'cargo run -p next-code-frame --bin code_frame -- -m "Unexpected token" src/app.tsx 10:5 10:20' adds an error message.
next-code-frame skip-scan heuristic for large files
For large files, the extract_highlights() function uses a skip-scan heuristic that walks backwards from the visible window looking for a blank line to start the regex tokenizer scan. This optimization avoids expensive scanning from byte 0. Blank lines are safe restart points for single-line constructs like strings, line comments, and regex literals because these constructs cannot span blank lines.
next-code-frame multi-line construct highlighting limitation
The skip-scan heuristic can produce incorrect highlighting when multi-line constructs like block comments or template literals contain a blank line between the scan start and visible window. In this case the scanner misses the opening delimiter and the closing delimiter or trailing code may lose expected coloring. This is a deliberate tradeoff because such cases are vanishingly rare and the consequence is only slightly wrong highlighting.
next-code-frame byte-level skip for long lines
When the visible window starts far into a long line (more than 200 bytes from the line-level scan start), the heuristic scans backwards from the visible start for a semicolon and restarts the tokenizer there. This is critical for minified files where the entire source may be a single line, preventing the scanner from tokenizing hundreds of kilobytes of invisible content.
next-code-frame semicolon skip limitation for minified code
When skipping backwards for a semicolon in long lines, the semicolon can land inside a string literal, causing unbalanced quotes that cascade incorrect highlighting across the visible window. In practice this rarely occurs in minified code due to frequent semicolons between statements, and the consequence is only incorrect highlighting, never a failure.
next-code-frame syntax highlighting capabilities
The next-code-frame highlighter supports syntax highlighting for JavaScript, TypeScript, JSX, and TSX files. It provides graceful degradation for non-JS files or parsing errors, includes ANSI color support matching babel-code-frame aesthetics, and supports single-line and multi-line error ranges. Caller-provided output width is used with no terminal detection.