Error handling pattern

Structure exception hierarchies for specific error types

When structuring exception hierarchies for specific error types (auth, rate limit, policy, etc.)

• · API response codes and error messages

• · Exception classes with proper inheritance and payload handling

• · HTTP status code mapping defined
• · Error code taxonomy available

• · Generic Exception used instead of specific subclass
• · Error payload not extracted (retry_after in RateLimitError)
• · HTTP error handler doesn't route all codes
• · Custom exception doesn't inherit from base KlingAIError

• · Specific exception classes for common API failure modes
• · Payload capture (retry_after, message) in exception init
• · HTTP status code routing in handle_api_error