Error Handling code review rules

Check if loops use equality operators (== or !=) in termination conditions. These can lead to infinite loops if the condition is never met exactly. Instead, use relational operators like < or > for safer loop termination.

Returning null from a Task or Task<T> method causes a NullReferenceException if awaited. Use Task.CompletedTask or Task.FromResult<T>(null) instead.

Detect `except` clauses that use `or` or `and` to catch multiple exceptions. This does not work as intended. Recommend using a tuple of exceptions instead.

Identify instances where an exception object is created but never raised. This is likely an oversight and should either be removed or properly raised.

Ensure that `assert` is not used for validating user input or critical checks. Assertions can be disabled in optimized mode (`python -O`). Recommend using explicit validation with `if` conditions and raising proper exceptions.

Check if every `case` statement includes an `else` clause. If an `else` clause is missing, ensure that a comment explicitly states why it is unnecessary.

Verify that all `if...elsif` constructs include a final `else` clause. If `else` is missing, ensure there is a comment explaining why all cases are covered.

Detect exception handling blocks that catch objects not derived from `BaseException`. This causes a `TypeError` and should be avoided.

Ensure that `SystemExit` and `KeyboardInterrupt` are not caught without being re-raised. Preventing Python from exiting can cause unintended behavior.

Ensure that 'this' is not used in functional components. Functional components do not have a 'this' context. Use props and destructuring for data access instead.

Log failures with operation name, key identifiers, and exception; prefer structured logging (fields).

Validate required parameters at boundaries using require/requireNotNull or explicit validators; fail fast with actionable messages.

Validate method inputs up front with null checks or use Objects.requireNonNull and meaningful messages.

Validate HTTP status and safely access nested response data using `dig`/guards.

Wrap HTTP/SDK calls with timeouts and catch transport/errors; log context and map to domain failures.

Wrap file reads/writes (e.g., file_get_contents, file_put_contents, fopen) with checks and exceptions; never assume the filesystem is available.

Always check and handle errors from json.Marshal/json.Unmarshal (or Encoder/Decoder). Log context and return a safe, consistent error to callers.

Guard app startup with zone-level handlers and FlutterError hooks; surface fatal errors and report them.

Validate required runtime env vars at container start via an entrypoint script; exit with a clear message on missing values.

Validate presence, type, and range of critical inputs at boundaries (API, CLI, jobs) and fail fast with clear messages.

When accessing properties that may be absent, use optional chaining and sensible defaults.

Guard all potentially-null references with null checks, null-coalescing, or pattern matching before dereferencing.

Catch and handle only the exceptions you expect (e.g., KeyError, ValueError, TimeoutError); let unknown ones bubble.

Wrap multi-statement DB operations in a transaction; commit on success and rollback on any exception.

Surround network and IPC calls with try/catch for IOException and timeouts; map to domain errors and log context.

Wrap network, file system, and other external calls in try/catch; add context and map to application-level errors.

Wrap network/filesystem/process calls; check status codes/results and add context to failures.

Check transport errors and HTTP status codes before parsing response bodies; treat 4xx/5xx as errors with context.

Do not use `return`, `break`, or `continue` inside `finally` blocks as they can suppress exceptions and lead to unintended behavior.

Ensure that constructors do not include asynchronous operations. Constructors should initialize class instances synchronously. If async logic is required, suggest moving it to a separate initialization method.

Ensure that `instanceof` checks are used before performing explicit type casting to prevent `ClassCastException`.

Detect missing commas in lists, tuples, or dictionaries that unintentionally concatenate strings. This can lead to unexpected behavior and hard-to-find bugs.

Detect function definitions that use mutable objects (lists, dictionaries) as default arguments. This can lead to unintended shared state. Recommend using `None` as the default and initializing the object inside the function.

Never swallow exceptions silently; log with context and either rethrow or handle explicitly.

Ensure that catch blocks do not remain empty. Empty catch blocks hide errors, making debugging difficult. Recommend logging or handling errors properly.

Ensure that catch blocks contain meaningful exception handling logic and do not remain empty.

Detect `except:` blocks that catch all exceptions indiscriminately. Using a broad `except:` can hide real issues and prevent necessary errors like `KeyboardInterrupt`. Recommend catching specific exceptions instead.

Identify function definitions where a mutable object (e.g., list, dictionary, set) is used as a default argument. This can cause shared state across function calls, leading to unintended behavior. Suggest using `None` as a default and initializing the object inside the function.

Do not silently catch and return null on errors; log context and either rethrow or return a typed failure/Result.

Detect the use of the 'any' type in TypeScript. Using 'any' disables type checking and can lead to runtime errors. Recommend using specific types or generics instead.

Detect cases of unsafe type assertions. These do not perform runtime checks and can lead to unexpected runtime errors. Recommend using proper type guards instead.

Do not use `!` to check nullable type parameters, as this can lead to runtime exceptions if the type itself is nullable.

Do not use constant patterns with type literals as it can lead to unexpected behavior. Prefer direct type checking instead.

Await Tasks instead of blocking (no .Result or .Wait()); prefer async/await end-to-end and configure awaits appropriately.

If the PR claims to fix a specific issue (e.g., 'Fixes #123' / 'Fix PAY-123'), validate it against the real production error. - If an observability MCP is available (Sentry/Datadog/Bugsnag): fetch the event/stack trace and confirm the change addresses the root cause. - Require a regression test (or a clearly documented reason why a test cannot be added). Call out fixes that only hide symptoms (catch-and-ignore, broader retries, defaulting values) without removing the underlying failure mode.

Verify that after loading a PyTorch model, either `model.eval()` or `model.train()` is called. Failing to do so can result in incorrect behavior, especially for layers like dropout and batch normalization.

Verify if a widget is still mounted before using `BuildContext` inside an asynchronous operation to prevent accessing invalid states.

Avoid assigning values to `void` variables as `void` is not a compatible type and doing so results in runtime errors.

Configure your application not to display detailed error messages (stack traces, PHP warnings) to end users in production. Instead, log errors for developers and show a generic message to users.

Ensure that all caught exceptions are either logged or handled properly. Empty catch blocks are not allowed.

Detect occurrences of the 'with' statement. This construct is banned in strict mode due to unpredictable behavior and makes debugging harder.

Identify functions that raise exceptions but do not document them in docstrings. Missing exception documentation makes it difficult to understand failure cases. Suggest adding an `:raises` section in the docstring.

Never compare the address of a variable to nil (e.g., `&x == nil`). To check if a pointer is nil, compare the pointer itself to nil. The address of a variable (`&x`) will always be non-nil if `x` exists.

Reserve `panic` for unrecoverable situations (like invariant violations or truly fatal errors). For expected error conditions (file not found, invalid input, etc.), return an `error` to the caller instead of panicking.

Check if the `__all__` list in a module contains titles that are not defined. Listing undefined titles can cause `ImportError` when performing wildcard imports.

Verify that `__init__` methods always return `None`. Returning any other value causes a `TypeError` and prevents correct object instantiation.

Identify function calls where the number of arguments passed does not match the expected parameters. This often results in a `TypeError`. Suggest reviewing function signatures.

Detect functions that mix `return` statements with values and those without. Inconsistent return usage can lead to unpredictable behavior.

Verify that special methods (e.g., `__eq__`, `__len__`) have the correct number of parameters. Incorrect parameters can cause runtime errors or unexpected behavior.

Check if resources such as files or database connections are properly closed in a `finally` block. This ensures resources are always released, even if an exception occurs.

Rescue RecordNotFound and return 404 (or domain-appropriate response) instead of 500.

Every awaited async operation must be guarded with error handling. Use try/catch for await and .catch for promise chains; never leave rejections unhandled.

Attach exceptionally/handle to CompletableFuture chains; never assume success.

Catch and map DB exceptions (e.g., SQLIntegrityConstraintViolationException) to domain results; always close resources with use { }.

Use transactions for multi-step writes; on Throwable, rollback and rethrow with context.

Never silently ignore an error, and avoid handling an error (e.g., logging it) and then still returning it. Either handle the error fully or propagate it upward, but not both.

Guard file IO with try/except; handle OSError and data parse errors with clear messages.

Use JSON_THROW_ON_ERROR (PHP ≥7.3) and wrap json_encode/json_decode in try/catch; validate the decoded shape.

Wrap multi-step writes in a transaction; on failure, roll back and rethrow with context.

Use the 'comma, ok' idiom for type assertions to safely handle cases when the assertion fails. Only use a single-value type assertion (which panics on failure) if you are absolutely sure (by prior checks or program logic) that the interface holds the correct type.

Detect transient vs non-transient DB errors; add context and apply retry policies only where safe (idempotent reads/operations).

Error logs must include the operation name and relevant identifiers as structured fields, not just a message string.

Every catch block must log or report the error at least once before handling or rethrowing.

Numeric overflows occur when values exceed the data type limits, leading to incorrect calculations. Use checked arithmetic where necessary.

Never swallow exceptions silently; wrap with context and rethrow or translate to a domain exception.

Guard early or use safe navigation when dereferencing possibly-nil data.

When subscribing to streams/listeners, always provide an error handler and a deterministic unsubscribe/cleanup path.

Do not swallow errors; log with context and re-raise using `raise` (no args) or `raise new_error, cause: e`.

Never swallow exceptions in catch blocks; either rethrow or return an explicit error result.

Ensure that React class components' render functions return a value. Forgetting a return statement results in missing UI elements and potential bugs.

Verify that collections are not modified directly during iteration. Instead, ensure safe removal techniques such as iterating over a copy or using `ToList()`.

Avoid the !! operator. Prefer safe calls, Elvis (?:), early returns, or explicit exceptions with a clear message.

Handlers must return non-2xx status codes for error outcomes and include a minimal error body that does not leak sensitive details.

Avoid bare `rescue`; rescue StandardError (or a narrower class) and log with context.

Background jobs must throw on irrecoverable failures (after logging) so the runner/queue can retry or dead-letter appropriately.

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.

Ensure `First()` or `Single()` is used instead of `FirstOrDefault()` or `SingleOrDefault()` when collections are guaranteed to have elements.

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.

Ensure that optional REST parameters use object types or `Optional<T>` instead of primitive types to avoid runtime errors.

When re-emitting a caught exception, use `rethrow` instead of `throw e` to keep the original stack trace.

Use `&.` and presence/|| to safely traverse possibly-nil chains and provide defaults.

Throw and catch the most specific exception type available; avoid catching or throwing System.Exception unless rethrowing.

Wrap per-item work in try/catch, collect failures, and continue when appropriate; never let one failure abort the entire batch by default.

Prefer TryParse-style APIs for user/IO input instead of Parse, and validate culture/format where applicable.

Use isset()/array_key_exists() or null coalescing (??) before reading array keys that may be absent.

Use try/catch (or Uri.tryParse with validation) around Uri.parse to guard against FormatException and invalid inputs.

Every match expression must define a default arm that handles unsupported or unexpected values.

Parse dates with DateTimeFormatter in try/catch and validate expected formats/timezones.

Include request-scoped fields (method, path, request_id, deadline/canceled) in error logs. Pass context through layers.

Ensure that resources such as files, sockets, or database connections are managed using the `with` statement. Code that explicitly calls `.close()` without `with` should be refactored to use context managers for automatic resource cleanup.

Check for occurrences of var declarations. Using var leads to function scoping issues. Recommend using const for immutable values and let for mutable ones.

Ensure that isFinite is used to validate numbers. Without this, NaN or Infinity can cause unexpected behavior and runtime errors.

Ensure that strict equality (===) is used instead of loose equality (==). Loose equality can lead to unexpected type coercion and logical errors.

Ensure that JSON data is validated before parsing. Parsing untrusted JSON without validation can result in runtime errors or vulnerabilities.

Detect floating-point numbers with excessive precision. Overly precise numeric literals can cause rounding errors and unexpected behavior in calculations.

Do not include internal identifiers (DB IDs, service IDs, tokens) in client-facing errors. Log them internally; return generic messages externally.

Ensure that arrays do not contain non-numeric properties. This practice can lead to unexpected behavior. Use Maps or Objects instead.

Identify `rescue Exception` statements and suggest replacing them with `rescue StandardError` to avoid catching critical system exceptions.

Do not use the error‐suppression operator '@' before function calls or expressions. Instead, handle potential errors properly using return checks or exceptions (try/catch).

Use `catch (e, stack)` and log both exception and stack; do not log message-only.

Validate collection bounds and query results before indexing; prefer FirstOrDefault/SingleOrDefault with null checks.

Define a discriminated union or error class hierarchy and use user-defined type guards before handling specific cases.

Always handle or log caught exceptions instead of silently ignoring them to improve debugging and maintain application stability.

Avoid empty catch blocks. When you catch an exception, implement meaningful handling: log the error, perform a fallback action, or rethrow after processing. Do not catch exceptions generically just to suppress them.

Ensure that imported variables are not reassigned. This can cause runtime errors, especially in TypeScript. Modify object properties instead of reassigning variables.

Detect occurrences of the Array constructor. It behaves inconsistently depending on arguments. Recommend using array literals [] instead for clarity and predictability.

Ensure that parameters to `==` are non-nullable. Avoid using nullable parameters as they can introduce unexpected behavior and null reference errors.

Check for the use of eval() to handle asynchronous execution. Eval leads to security vulnerabilities. Recommend using Async/Await or Promises instead.

Check for variables, functions, or classes that are used but not defined. This results in `NameError` and should be fixed by ensuring all symbols are properly declared.

Centralize validation in dedicated functions/objects and reuse; return typed errors.

When using Optional/CompletableFuture/Publisher-like types, map empty values to a clear outcome (e.g., 404) rather than returning null.

Use ?? and the nullsafe operator (?->) to provide defaults and avoid notices when values may be null.

Always provide `orElse` to firstWhere (or use a safe helper) when the match may not exist.

Parse dates/times in begin/rescue blocks and validate expected format/timezone.

Set sensible defaults for properties/fields or enforce via constructors.

Always initialize variables before use and avoid conditionally-defined locals.

Detect `try` blocks that contain excessive code. Large `try` blocks make it harder to debug errors. Recommend narrowing the scope of the `try` block to only the necessary code.

In when/else or default branches, log a warning with the unexpected value to surface silent failures.

Check for hash key lookups without default values. If a missing key is accessed, suggest using `fetch` with a default value.

Centralize repeated dialog creation/action handlers into a helper to ensure consistent UX and error handling.

Break deep map/flatMap chains into named suspend functions or use runCatching/Result for clearer composition.

After using external resources (DB connections, open files, sockets), release them properly. Use fclose(), close database connections or finally blocks to ensure cleanup even if errors occur.

Use safe casts (as?) with null checks or require statements instead of unchecked as.

When returning (T, error), return the zero value for T (or nil for pointers/slices/maps) whenever error != nil.

When using iota to create enums (constant sets), start from 1 and use 0 as a 'zero value' meaning undefined or default. This way, an uninitialized variable of that enum type will not accidentally hold a valid value.

Identify occurrences where `== None` or `!= None` is used. Using `is None` and `is not None` is more reliable because it checks identity instead of equality, preventing potential issues with overloaded `__eq__` methods.

Error strings should start with a lowercase letter and not end with punctuation. They should state what went wrong in a concise, factual manner (for example, "file not found", not "File not found!").

Ensure that exception variables in `rescue` blocks use meaningful titles instead of generic ones like `e`.

When keys may be absent, prefer dict.get(key, default) or setdefault instead of direct indexing.

Use safe calls (?.), the Elvis operator (?:), let/run/also for scoped handling, and early returns for invalid input.

For many independent tasks, prefer Promise.allSettled and handle per-item results.

Use the as operator or pattern matching for safe casts and guard null results before usage.

Ensure that resources such as streams or file handlers are managed using try-with-resources to avoid leaks.

Use instanceof/pattern matching and guard before casts; avoid ClassCastException.

When returning an error from a function, include contextual information. Use `fmt.Errorf` with `%w` (or similar error wrapping) to add a message while preserving the original error.