Windsurf prompt to add error handling
This prompt treats error handling as an audit, not a sprinkle of try-catch: Cascade searches the repo for bare awaits and empty catch blocks, groups findings by file, and fixes them in layers with a forced-failure test for each. You leave Windsurf with one middleware boundary and proof that every path fails safely.
Last updated
Audit this repo for missing error handling and fix it in layers. Start with a Cascade search for bare awaits, empty catch blocks, and promise chains without rejection paths; group findings by file and show me before editing. Then add a shared asyncHandler around route handlers, one error middleware mapping known error types to status codes and hiding stack traces outside development, and a timeout plus typed failure result on every external call: network, filesystem, {{database}}. On the UI side, wrap the route tree in an error boundary with a retry action. Every fix ships with a test that forces the failure: reject the promise, sever the connection, throw inside a child component. Run the suite from the Windsurf terminal and report each forced-failure test you added.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Audit this repo for missing error handling and fix it in layers. Start with a Cascade search for bare awaits, empty catch blocks, and promise chains without rejection paths; group findings by file and show me before editing. Then add a shared asyncHandler around route handlers, one error middleware mapping known error types to status codes and hiding stack traces outside development, and a timeout plus typed failure result on every external call: network, filesystem, PostgreSQL. On the UI side, wrap the route tree in an error boundary with a retry action. Every fix ships with a test that forces the failure: reject the promise, sever the connection, throw inside a child component. Run the suite from the Windsurf terminal and report each forced-failure test you added.
Same task in other tools
Questions about this prompt
What does the layered order buy me?
Fixing the middleware boundary first gives individual handler fixes somewhere consistent to throw to. Going call-site first produces fifty bespoke catch blocks that all format errors differently.
How do I adapt this for a frontend-only project?
Drop the middleware layer and keep the search step, the error boundary, and the timeout-wrapped fetches. Ask Cascade to also cover event handlers, since boundaries do not catch errors thrown there.
Tests pass but production still shows stack traces. Why?
The environment check in the error middleware is comparing against the wrong variable, or the deploy sets it unexpectedly. Have Cascade grep every place the environment is read and consolidate them into one config module.