error-handling-patterns

Use a decorator that wraps the function, catches specified exceptions, and sleeps for backoff_factor raised to the attempt number between retries. After the maximum attempts are exhausted, it re-raises the last exception so callers can handle the failure.

Use Result types for expected errors like validation failures where callers should explicitly handle outcomes. Use exceptions for unexpected, exceptional conditions. Result types make failure paths visible in function signatures, while exceptions suit truly exceptional control flow.

A circuit breaker tracks failure counts and opens after a threshold, rejecting requests immediately instead of calling the failing service. After a timeout it enters half-open state to test recovery, closing again once enough successes occur.

Wrap errors with fmt.Errorf using the %w verb to preserve the error chain. Use errors.Is to compare against sentinel errors and errors.As to extract custom error types like ValidationError from the wrapped chain.

Avoid catching overly broad exception types, empty catch blocks that swallow errors, logging and re-throwing which duplicates log entries, and forgetting to clean up resources. Use context managers, try-finally, or defer for cleanup.