Skip to main content

Overview

All SDK errors inherit from Law4DevsError. Each exception class maps to a specific HTTP status code or error condition. The SDK automatically retries transient errors (429 and 5xx) with exponential backoff before raising.

Exception Hierarchy

All exceptions expose a status_code attribute containing the underlying HTTP status code.

Exception Reference

Law4DevsError

Base class for all SDK exceptions. Catch this to handle any API error.
AttributeTypeDescription
status_codeintHTTP status code
messagestrHuman-readable error message

NotFoundError

Raised when the requested resource does not exist (HTTP 404).

ValidationError

Raised when the request parameters are invalid (HTTP 400 or 422).

RateLimitError

Raised when the rate limit is exceeded and all retries are exhausted (HTTP 429).

ServerError

Raised when the server returns a 5xx response and all retries are exhausted.

Auto-Retry Behaviour

The SDK automatically retries failed requests on HTTP 429 and 5xx responses. Retries use exponential backoff with jitter.
  • Default retries: 3
  • Backoff: 1s, 2s, 4s (with jitter)
  • Retried status codes: 429, 500, 502, 503, 504
If all retries are exhausted, the appropriate exception (RateLimitError or ServerError) is raised. Configure the retry count at construction time:

Practical Patterns

Handle a missing resource

safe_get helper

A utility that returns None instead of raising on 404:

Catch all API errors

Handle rate limits explicitly

Distinguish error types

Validate a framework slug before use


Timeout Errors

Network timeouts raise Python’s built-in TimeoutError (not a Law4DevsError). Configure the timeout per client:
For batch jobs that process thousands of items, set max_retries=5 and a generous timeout=60. The SDK will handle intermittent failures automatically.
404 responses are not retried automatically — they indicate a resource genuinely does not exist, not a transient failure.