Travel Booking API — Error Handling Setup

Problem Description

The engineering team at a travel booking startup is building a new .NET 8 REST API for their flight search and reservation service. The API will be consumed by a mobile app and third-party travel agents, both of whom need machine-readable error responses they can reliably parse and display to end users.

Currently the prototype has no centralized error handling: if something goes wrong, clients receive raw ASP.NET Core 500 responses or HTML error pages. The product team has been told by a major travel agency partner that they require error responses to conform to RFC 7807 (the HTTP Problem Details standard), as their client SDK knows how to parse that format automatically.

Your job is to build out the error handling layer for this API. There are three domain-specific error conditions that need typed representations: a resource not found (e.g. flight or booking not found), a business rule violation (e.g. trying to cancel a flight that already departed), and a conflict (e.g. seat already booked by another user). All of these should flow through a single, centralized handler rather than being scattered across individual controllers.

Output Specification

Produce the following files in your working directory:

• GlobalExceptionHandler.cs — the centralized exception handler class
• Exceptions.cs — the custom exception type definitions
• Program.cs — the application startup/pipeline configuration registering the handler and mapping a single sample controller route
• error_handling_notes.md — a brief explanation (2–4 sentences) of how the error handling is wired up and how a client can identify error types from the response

The files should form a coherent, self-consistent implementation. The GlobalExceptionHandler.cs and Program.cs should reflect how the handler is registered and invoked in .NET 8.