Ask Claude to Add Error Handling to Code That Only Covers the Happy Path
First drafts of code usually handle the success case and nothing else. That works until it doesn't — and "it doesn't" always happens in production. Claude reads your happy-path code and adds the error handling it needs.
"Read the checkout flow and add error handling for every failure mode"
Claude traces each step that can fail — network calls, database writes, payment processing, email sending — and wraps them with proper error handling:
// Before: happy path only
$charge = $stripe->charges->create($params);
$order->update(['status' => 'paid']);
Mail::send(new OrderConfirmation($order));
// After: Claude adds real error handling
try {
$charge = $stripe->charges->create($params);
} catch (CardException $e) {
return back()->with('error', 'Your card was declined. Please try another.');
} catch (ApiException $e) {
Log::error('Stripe API error', ['error' => $e->getMessage()]);
return back()->with('error', 'Payment processing is temporarily unavailable.');
}
$order->update(['status' => 'paid']);
try {
Mail::send(new OrderConfirmation($order));
} catch (Throwable $e) {
Log::warning('Order confirmation email failed', ['order' => $order->id]);
// Don't fail the checkout — the order succeeded
}
You can focus on specific types of failures:
# External service failures
"Add error handling for when the API is down, slow, or returns unexpected data"
# Database errors
"Handle constraint violations, deadlocks, and connection timeouts in the repository layer"
# User input edge cases
"Add validation and error handling for all the ways user input can be wrong or malicious"
# Graceful degradation
"Make the dashboard work even when the analytics service is unavailable — show cached data or a helpful message"
Claude distinguishes between errors that should block the operation and ones that should be logged but not stop the flow — a failed notification shouldn't cancel a successful purchase.
The happy path is a demo. Error handling is what makes it production code — let Claude add the safety nets you forgot.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.