error-handling

Convert .NET failures and exceptions into RFC 9457 ProblemDetails responses.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/shahdanish/vibepos --skill error-handling-shahdanish
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: error-handling
Source: https://github.com/shahdanish/vibepos/tree/main/skills/error-handling
Command: npx skills add https://github.com/shahdanish/vibepos --skill error-handling-shahdanish

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents inconsistent, hard-to-debug error responses in .NET applications by standardizing how expected failures and unexpected exceptions are transformed into RFC 9457 ProblemDetails.

Core Features & Use Cases

  • Result pattern for expected failures: Use Result/Result<T> to represent business-rule outcomes like “not found” or “validation failed” without throwing exceptions.
  • Typed mapping to ProblemDetails: Convert failures into structured ProblemDetails responses that include type, title, status, detail, and optional errors.
  • Global exception handling: Catch unexpected exceptions once and return a safe, consistent 500 response with optional development-only detail.
  • FluentValidation at the boundary: Validate requests using FluentValidation and return ValidationProblem details via endpoint filters.

Quick Start

Load this skill when implementing error handling, validation, or API error contracts in your .NET 10 endpoints so your failures consistently return RFC 9457 ProblemDetails.

Frequently Asked Questions about error-handling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I standardize .NET API error responses using RFC 9457 ProblemDetails?

Standardize .NET API error responses by converting expected failures and unexpected exceptions into consistent RFC 9457 ProblemDetails payloads. This approach replaces inconsistent error formats with structured responses containing type, title, status, and detail fields.

What is the Result pattern for handling expected business failures without throwing exceptions?

The Result pattern represents business-rule outcomes like validation failures using Result or Result<T> objects instead of throwing exceptions. This allows typed mapping to structured ProblemDetails responses for predictable error handling.

How do I configure FluentValidation to return ValidationProblem details at the API boundary?

Configure FluentValidation at the API boundary using endpoint filters to intercept invalid requests and return structured ValidationProblem details. This ensures validation failures consistently map to RFC 9457 ProblemDetails responses.

How does a global exception handler prevent sensitive error detail leakage in production .NET APIs?

A global exception handler catches unexpected exceptions once, logs the details, and returns a safe 500 response. It provides optional development-only detail to prevent sensitive error detail leakage in production environments.

Can I use this structured error handling approach with .NET 10 minimal API endpoints?

Yes, this RFC 9457 ProblemDetails error handling approach applies directly to .NET 10 endpoints. It integrates boundary validation, Result pattern mapping, and global exception handling to return consistent API error contracts.

Why should I map Result patterns to ProblemDetails instead of relying on default .NET error formats?

Mapping Result patterns to typed ProblemDetails prevents inconsistent, hard-to-debug error responses. It standardizes API error contracts by transforming expected failures and unexpected exceptions into structured RFC 9457 payloads.