Error Handling rules

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.