java-error-handlinglisted

# Error handling for an APIMatic Java SDK Every blocking operation declares **two** checked exceptions: ```java public {ReturnType} {operation}({params}) throws ApiException, IOException ``` - **`ApiException`** — the server answered, but not with a success status. Lives in `<root>/exceptions/` and extends the runtime's `CoreApiException`. - **`IOException`** — the request never completed: connection refused, DNS failure, TLS error, socket timeout. It is *not* an `ApiException`, so a catch block that only handles `ApiException` will not compile without also handling it. - **`AuthValidationException`** (`io.apimatic.core.exceptions`) — **unchecked**, so it appears in no `throws` clause. Thrown before the request is sent when a required credential is missing or an OAuth token cannot be obtained. It extends `RuntimeException`, so neither `catch (ApiException)` nor `catch (IOException)` covers it: add an explicit `catch (AuthValidationException e)`, or let it escape as the configuration bug it is. See the *Notes* below. XML-based operations add `JAXBException`. ## Two shapes of `ApiException` - **Typed subclass (Case A)** — for an error response the spec gives a **modelled body**, the generator emits a per-error class under `<root>/exceptions/` extending `ApiException`, with Jackson-annotated fields and public getters for the error payload. At least one error in this API has such a body, so those classes exist. `doc/controllers/{group}.md` has an **Error