What problem does it solve? Catching errors from an APIMatic-generated .NET SDK is easy to get wrong: the thrown SdkException<TError> carries either a typed per-operation error model or a raw error body, and a catch ladder written from memory silently drops responses, leaks internal type names, or misses connection failures entirely. ## Core Features & Use Cases - Two-case exception model: Distinguishes operations that throw SdkException<{Operation}Error> (typed model with TryGet* accessors) from those that throw SdkException<RawError>, with the correct namespaces and using directives for each. - Complete catch ladders: Enumerates every TryGet* accessor on the typed error model, orders TryGetRawError last, and explains why factoring error reading into an ApiError-typed helper loses typed bodies. - Non-throwing alternative: Covers the optional {Operation}Result sibling method returning ApiResult<TResponse, TError>, which exposes status codes and headers on both success and failure. - Use Case: While writing a service that calls a payments endpoint, you add a try/catch around the SDK call; the skill tells you the exact exception type to catch, every accessor branch to write, and how to convert connection failures and JSON parse failures into your own boundary error type without leaking framework details. ## Quick Start Ask the agent to write the error handling for a specific SDK operation, for example: write the try/catch for the CreateWidget call using the dotnet error handling skill.
