Validate error handling completeness across languages
56
71%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
catch (e) { } or catch { } — the error is caught but the body does nothing.try { await fetch(url) } catch (e) { }..catch(() => {}) or .catch(() => undefined) — rejection handler that does nothing.fetchData().catch(() => {}).catch (e) { return defaultValue } without any logging or re-throw.catch (e) { ... } that handles the error but catches all error types without narrowing (e.g., no instanceof check) and does not re-throw.catch is inherently untyped (unknown or any), so every catch block technically matches this pattern. Flagging as advisory rather than requiring justification avoids excessive noise while still surfacing the pattern for review.catch (e) { console.error(e) } with no re-throw or return.console.error is often not sufficient for production error tracking. May be intentional in development-only code.Promise without await, .then(), or .catch().deleteOldRecords() where deleteOldRecords is async.void deleteOldRecords() — explicitly marks fire-and-forget intent.void.