php-error-handlinglisted

# Error handling for an APIMatic PHP SDK ## First: where does a failure surface? Two independent facts about this SDK decide it, and **the first is already settled**: it returns the `ApiResponse` wrapper — either it was built to return complete responses, or it never raises on an error status, either of which produces the wrapper — so `src/Http/ApiResponse.php` is generated, every operation returns the wrapper, and **an error status never raises**. Each handler chain ends `->returnApiResponse()`, which makes the runtime return the wrapper on a failure instead of throwing. One question is left, and the filesystem answers it — settle it before you write any `try`: > **Does `src/Exceptions/ApiException.php` exist?** (an SDK that maps its error types into the response > omits it) > - **Yes** → there is something throwable, but only for a **transport** failure; a non-2xx still comes > back inside the wrapper. > - **No** → nothing is throwable at all. The classes under `src/Exceptions/` are plain error *models*, > and a `try/catch` around a call catches nothing — not even a network failure. That leaves two builds this SDK can be: | `ApiException.php` | A non-2xx status | A transport failure | | --- | --- | --- | | present — the **wrapper build** | returns the wrapper; `getResult()` is the **raw decoded body** | throws `ApiException` with a `getCode()` of `0` | | absent — the **mapped build** | returns the wrapper; `getResult()` is the **deserialized error model** for any s