error-handling

To standardize exception hierarchies across application layers, define explicit exception classes for the Domain, Infrastructure, and Application layers. This ensures consistent error propagation rules and maintains logical separation between different architectural boundaries.

The best way to handle retryable errors for external service integrations is to explicitly document the distinction between retryable and non-retryable exceptions. This allows you to implement targeted retry semantics for transient failures without masking permanent issues.

Proper error chaining with from e matters during code reviews because it preserves the original traceback and debug context when re-raising exceptions. This prevents information loss and significantly reduces the time needed to diagnose root causes in complex I/O or LLM integrations.

To avoid broad exception catches when integrating new external services, define and raise explicit exception classes tailored to the specific failure modes of the service. Update except blocks to catch these specific types rather than using generic exception handlers.

You need explicit exception classes for LLM integrations when you must distinguish between transient network failures and permanent model invocation errors. This distinction enables standardized retry semantics and robust error handling for external service dependencies.

Using generic exceptions for I/O operations limits your ability to implement targeted retry logic and obscures the root cause of failures. Without explicit exception types, you cannot effectively distinguish between retryable transient errors and permanent infrastructure failures.