Error Handling rules

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.