Every catch block must log or report the error at least once before handling or rethrowing.
error-handlingobservability-logging
High
Prevent Numeric Overflow in Calculations
Numeric overflows occur when values exceed the data type limits, leading to incorrect calculations. Use checked arithmetic where necessary.
error-handling
High
Propagate exceptions instead of hiding failures
Never swallow exceptions silently; wrap with context and rethrow or translate to a domain exception.
error-handlingobservability-logging
High
Protect against NoMethodError on nil objects
Guard early or use safe navigation when dereferencing possibly-nil data.
error-handling
High
Provide error handlers to subscription/listener APIs
When subscribing to streams/listeners, always provide an error handler and a deterministic unsubscribe/cleanup path.
error-handlingui-robustness+1
High
Re-raise exceptions to preserve error context
Do not swallow errors; log with context and re-raise using `raise` (no args) or `raise new_error, cause: e`.
error-handling
High
Re-throw or return errors to propagate failures
Never swallow exceptions in catch blocks; either rethrow or return an explicit error result.
error-handling
High
React "render" functions should return a value
Ensure that React class components' render functions return a value. Forgetting a return statement results in missing UI elements and potential bugs.
error-handlingstack-react+1
High
Remove Items Safely During Iteration
Verify that collections are not modified directly during iteration. Instead, ensure safe removal techniques such as iterating over a copy or using `ToList()`.
error-handling
High
Replace null assertions with explicit null handling
Avoid the !! operator. Prefer safe calls, Elvis (?:), early returns, or explicit exceptions with a clear message.
error-handlingreadability-refactor
High
Return proper HTTP status codes for errors
Handlers must return non-2xx status codes for error outcomes and include a minimal error body that does not leak sensitive details.
api-conventionserror-handling+2
High
Specify StandardError explicitly in rescue blocks
Avoid bare `rescue`; rescue StandardError (or a narrower class) and log with context.
error-handlingobservability-logging
High
Throw exceptions on job failures
Background jobs must throw on irrecoverable failures (after logging) so the runner/queue can retry or dead-letter appropriately.
error-handlingobservability-logging+1
High
Use `finally` for Resource Cleanup
Detect code where resources (files, sockets, etc.) are not closed in a `finally` block. Using `finally` ensures that resources are released, even if an exception is raised.
error-handlingperformance-efficiency+1
High
Use `First`/`Single` Instead of `FirstOrDefault`/`SingleOrDefault` for Non-Empty Collections
Ensure `First()` or `Single()` is used instead of `FirstOrDefault()` or `SingleOrDefault()` when collections are guaranteed to have elements.
error-handling
High
Use defer to Release Resources
Always use `defer` to release resources like files or locks when a function has multiple exit points. Open or lock resources and immediately defer their close/unlock to ensure they get released on every code path.
error-handlingui-robustness
High
Use Object Types for Optional REST Parameters
Ensure that optional REST parameters use object types or `Optional<T>` instead of primitive types to avoid runtime errors.
api-conventionserror-handling
High
Use rethrow to preserve stack traces
When re-emitting a caught exception, use `rethrow` instead of `throw e` to keep the original stack trace.
error-handlingstack-flutter
High
Use safe navigation operator for nil checks
Use `&.` and presence/|| to safely traverse possibly-nil chains and provide defaults.
error-handling
High
Use specific exception types over generic Exception
Throw and catch the most specific exception type available; avoid catching or throwing System.Exception unless rethrowing.
error-handlingstyle-conventions
High
Use try-catch blocks in batch processing
Wrap per-item work in try/catch, collect failures, and continue when appropriate; never let one failure abort the entire batch by default.
error-handlingresilience-retries-idempotency+1
High
Use TryParse for string conversions
Prefer TryParse-style APIs for user/IO input instead of Parse, and validate culture/format where applicable.
error-handlingsecurity-hardening
High
Validate array keys before accessing
Use isset()/array_key_exists() or null coalescing (??) before reading array keys that may be absent.
error-handlingstack-php
High
Wrap Uri.parse in try-catch blocks
Use try/catch (or Uri.tryParse with validation) around Uri.parse to guard against FormatException and invalid inputs.