Error handling strategy for .NET 10 applications. Covers the Result pattern, ProblemDetails (RFC 9457), global exception handling, FluentValidation, and structured error responses. Load this skill when implementing error handling, validation, or designing API error contracts, or when the user mentio

Error Handling Core Principles 1. Use the Result pattern for expected failures — Don't throw exceptions for things like "order not found" or "validation failed". These are expected outcomes, not exceptional conditions. See ADR 002. 2. Reserve exceptions for unexpected failures — Database connection lost, null reference bugs, network timeouts — these are truly exceptional and should propagate to the global handler. 3. Every API error returns ProblemDetails — RFC 9457 is the standard. Every error response has type , title , status , detail , and optionally errors . 4. Validate at the boundary — Validate incoming requests at the API layer, not deep inside business logic. Patterns Result Pattern A simple, generic result type that carries either a value or errors. Result to ProblemDetails Mapping Global Exception Handler Catches unexpected exceptions and converts them to ProblemDetails. For the modern IExceptionHandler approach (preferred), see knowledge/common infrastructure.md . The inline lambda below works for simple cases: FluentValidation with Endpoint Filters Typed Error Results For richer error handling, use typed error enums or error objects. Anti patterns Don't Throw Exceptions for Flow Control Don't Return Raw Error Strings from APIs Don't Catch and Swallow Exceptions Decision Guide Scenario Recommendation Expected business failure Result pattern Input validation FluentValidation with endpoint filter Unexpected crash Global exception handler → ProblemDetails API error format RFC 9457 ProblemDetails — always Validation in handler Return Result.Failure, don't throw External service failure Catch specific exception, return Result.Failure Logging errors Structured logging with correlation ID

error-handling