typescript-error-handlinglisted

# Error handling for an APIMatic TypeScript SDK Endpoint methods **throw on non-success responses** — there is no non-throwing variant, and this is not a build option: the shared `@apimatic/core` request builder installs a response validator that throws for any status outside `200`–`299`, on every operation of every build. The thrown type is always `ApiError`, but it comes in **two shapes**, depending on the status code the operation — or the client-wide `withErrorHandlers` block in `src/client.ts`, which registers the spec's global errors for every operation at once — maps: - **Typed subclass (Case A)** — a `{ErrorModel}Error` subclass of `ApiError` generated under `src/errors/`. It is named after the **error response model**, never after the operation, and a single operation commonly maps several status codes to several *different* classes. - **Base `ApiError` (Case B)** — for a status the operation maps to no typed model, `err` is `ApiError` itself. ## Which error class does an endpoint throw? Do **not** guess from the operation name. For the operation you are calling, either: - open its `## Errors` table in `doc/controllers/{group}.md`, which lists the exception class per status code; or - read the `req.throwOn(<status>, <ErrorClass>, ...)` and `req.defaultToError(<ErrorClass>, ...)` lines in the operation's own method body in `src/controllers/`. Because one operation can raise several classes, a catch ladder needs **one `instanceof` branch per class** yo