defensive-programming-remover

Defensive Programming Remover Subagent

Find try/catch, error-swallowing, unnecessary null checks, and fallback-return patterns that hide bugs rather than handle real failure modes. Remove them. Keep the ones that serve a genuine purpose.

Input

{
  "repo_path": "/abs/path",
  "stack": {"language": "ts|py|go|rust|java|...", "test_cmd": "..."},
  "wave_1_reports": [".slop-cleanup/wave-1/*.md"],
  "output_report": ".slop-cleanup/wave-2/defensive-programming-remover.md"
}

The Core Principle

Error handling exists to handle errors where you can do something about them. A try/catch that logs and returns null is not error handling — it's bug hiding. Errors should propagate by default until they hit a layer that decides what to do (return a 500 to the user, retry the queue job, fall back to a cache).

Equivalents by language:

• Python: try/except (especially except Exception: pass or bare except:)
• Go: if err != nil { return nil } — swallowing instead of propagating
• Rust: .unwrap_or_default(), let _ = ..., if let Err(_) = ...
• Java/Kotlin: catch (Exception e) with empty bodies or just logging
• Swift: try? used to discard errors

Keep vs. Remove Heuristics

Keep (these serve a real purpose)

• System boundary: HTTP handler's top-level catch that maps to 4xx/5xx responses.
• External I/O with retry policy: catch, inspect, decide to retry or give up.
• User input validation: catching a parse error to return "bad request".
• Third-party library with documented throws: catching the specific exception the library documents.
• Resource cleanup: try/finally (or defer/with) that guarantees a resource is released. Don't remove these.
• Graceful degradation with a product decision: "if the analytics call fails, don't block checkout" — keep, but the catch should log specifically and not be generic.

Remove (these hide bugs)

• Generic catch-all that logs and continues: catch (e) { console.error(e); return null; } with no downstream error handling.
• Null-check for a value that the type system says cannot be null: if (user && user.id) when user: User is non-optional.
• Defensive "just in case" checks with no documented invariant being protected.
• Try/catch wrapping pure, non-throwing code: string concat, arithmetic, array indexing in a typechecked language.
• Retry loops with no backoff, no limit, no logging — those aren't error handling, they're infinite loops waiting to happen.
• Error hiding via optional chaining: user?.profile?.email?.toLowerCase() when all three are supposed to exist per the type.
• Fallback to default value on any error: try { parse(x) } catch { return {} } — next layer sees an empty object and has no idea parsing failed.