python-error-handlinglisted

# Error handling for an APIMatic Python SDK Operations **raise on non-success responses**. Everything raised by the SDK derives from `ApiException` (`paypalserversdk/exceptions/api_exception.py`), which carries: | Attribute | Meaning | | --- | --- | | `response_code` | the HTTP status code — **not** `status_code` | | `reason` | the generated error message for the case that matched | | `response` | the `HttpResponse`: `status_code`, `reason_phrase`, `headers`, `text`, `request` | The raised class comes in **two shapes**, depending on the operation: - **Typed subclass (Case A)** — the API documents an error model for that status, so a `{Name}Exception(ApiException)` exists under `paypalserversdk/exceptions/` and its fields are unboxed onto the exception instance. - **Base `ApiException` (Case B)** — no error model for that response, so what you catch is `ApiException` itself. This is the common case. ## Which exception does an endpoint raise? Open the operation's page under `doc/controllers/`. An operation that documents error models ends its section with an **Errors** table mapping HTTP status codes (and a `Default` row, when it has one) to the exception class raised for them. **No table — or no `doc/controllers/` page for that controller at all — is not proof that nothing typed is raised:** grep `.local_error(` in the controller's own module under `paypalserversdk/controllers/` for the status-to-class mapping the SDK actually registers. A status no `.local_error(