Validate error handling completeness across languages
56
71%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
{
"name": "error-handling",
"version": "1.0.0",
"input": ["git diff (all files)"],
"output_schema": "hard/should/warn with JSON structure (unified)",
"assumes": [],
"optional_tools": ["LSP (hover for type enrichment — graceful fallback to text matching)"],
"scope": [
"Swallowed errors and empty catch/except blocks",
"Ignored error returns and discarded error values",
"Silent fallbacks returning defaults without logging or propagation",
"Overly broad catching (bare except, untyped catch)"
],
"excludes": [
"Error message wording or style",
"Security implications of error handling",
"Exception chaining style (from e)",
"Error wrapping format (%w vs %s)",
"Logging configuration or format",
"Code style or formatting"
],
"hard_rules": [
"Ignored error returns (_ = in Go)",
"Empty catch/except blocks",
"Bare except: in Python",
"Broad except Exception: without re-raise in Python",
"Swallowed promise rejections in TypeScript"
],
"should_rules": [
"Silent fallback returns (return None, return default) without logging",
"Catch returns default without logging in TypeScript"
],
"warn_rules": [
"Errors only logged but not propagated",
"Broad catch without re-throw in TypeScript",
"Console-only error handling in TypeScript",
"Floating promises"
],
"references": [
"Error Handling Completeness"
],
"batch_size": 50
}