Error handling
Choose a failure path
Compare HTTP response errors and runtime exceptions.
Open a case to inspect its status, loader behavior, and route boundary. Each example intentionally triggers a failure.
Choose a failure path.
Every route below demonstrates a different way the app can fail and how the route-level boundary reshapes that failure into something inspectable.A request was understood, but the user is not authenticated.
Simulates a protected route where credentials are required before the request can continue.
Open case403The request is known, but the current actor is not allowed to proceed.
Shows the difference between being unauthenticated and being blocked after authentication.
Open case404Use this when a path or resource should report that it does not exist.
Throws a 404 `Response` so the route boundary can render a missing-resource state.
Open case500A generic server-side failure became an HTTP error response.
Models an internal server failure where the route cannot produce a normal response.
Open case502The app responded, but one dependency upstream failed first.
Represents an upstream dependency that answered incorrectly or with unusable data.
Open case503The service is alive enough to answer, but not ready to fulfill the request.
Useful for downtime and maintenance states where the route should advertise temporary unavailability.
Open caseruntimeRuntime exceptions
A thrown JavaScript error instead of an HTTP response.
Open caseHow the error routes work
The interesting split is between the static entry page, the dynamic route loader, and the boundary that formats both response errors and thrown exceptions.
Prerendered index
`/errors` is safe to prerender because it never throws.
Request-time loader
`/errors/:code` throws from the loader to simulate real failures.
Route boundary
The route boundary catches the failure and turns it into the final visual surface.