Bolt prompt to add error handling
Run this in an existing Bolt project to retrofit error handling in three layers: route-level boundaries in the UI, normalized typed failures in the data layer, and a pluggable logging hook. It also demands proof, a dev-only panel that forces each failure kind through real code paths so you watch every fallback render in the preview.
Last updated
Go through this project and add consistent error handling in three layers, without changing any feature behavior. 1. UI layer: wrap each route-level component in an error boundary that renders an inline fallback with a retry button, never a blank screen. Form submissions must show field-level validation messages plus a summary at the top of the form when a request fails. Every async button gets a loading state and is disabled while a request is in flight, to prevent double submits. 2. Data layer: centralize fetch calls in one module if they are not already. Normalize failures into a typed AppError with a kind (network, validation, auth, not_found, server), a message, and the original cause. Map HTTP statuses to those kinds. Retry idempotent GET requests once on network failure; never retry mutations automatically. 3. Reporting: add a small logError helper that logs structured errors to the console in development, with a clearly marked hook where a real error-tracking service can plug in later. Do not add a third-party dependency for this. Specific cases to cover: offline (failed fetch), a 401 that redirects to login exactly once instead of looping, a 404 on a detail page rendering a not-found view with a link back to the list, and a JSON parse failure from a malformed response. Before finishing, prove each path in the preview: add a dev-only panel with buttons that force every error kind through the real code paths, then tell me which files you changed. No empty catch blocks anywhere; if a catch exists only to ignore an error, add a comment explaining why that is safe.
Same task in other tools
Questions about this prompt
Will Bolt refactor unrelated code while adding error handling?
It can, because it tends to rewrite whole files it opens. The instruction to change no feature behavior plus the changed-file list gives you something to audit. If an unrelated file got rewritten, ask for that specific file to be restored to its previous version.
Why does the prompt forbid automatic retries on mutations?
A POST that times out may still have succeeded server-side, so retrying it blindly can create duplicate records or double charges. Only idempotent GETs are safe to retry without a dedupe key, and adding idempotency keys is a separate task.
Should the dev-only error panel ship to production?
No. Gate it behind a development check such as import.meta.env.DEV so production builds drop it entirely. Before deploying through the Netlify integration, ask for confirmation that the panel is excluded from the built output.