Resilience and observability
Error handling: from exception to meaningful response
Separating expected failures from unexpected ones, and responding without leaking internals.
Understand the concept
Not all errors are equal. Expected failures are part of the workflow: record not found, slug already used, no permission. These should be returned without throwing, with a fitting status code (404, 409, 403). Unexpected errors are situations the program did not foresee: the database unreachable, a null reference, a dependency crashing. These should rise to the outermost exception handler.
Writing try/catch in every layer is usually harmful: code that catches and swallows an exception, or merely logs it and carries on, hides where the error really happened and leaves inconsistent state. Catch an exception only if you can do something meaningful with it: retry, fall back to another source or translate it into a more meaningful error.
In ASP.NET Core, UseExceptionHandler and IExceptionHandler catch unexpected exceptions centrally, log them and return ProblemDetails to the client. In production a stack trace, SQL text or connection string never goes into the response; a traceId is provided instead. The simulator’s ‘Database failure’ scenario shows this flow.
Good error handling gives both the user and the developer the right information.
Swallowing errors with catch (Exception) { } or returning ex.ToString() to the client.
A letter’s journey through the city
Think of a request as a letter and the server as a city. Pick a scenario, press play and watch which gates the letter passes and where it gets stopped.
An ordinary post request sets off.
One topic. Three levels of depth.
// Beklenen durum: istisna değil, sonuç
var post = await posts.GetPublishedAsync(slug, ct);
return post is null ? NotFound() : Ok(post);Not found is a possible outcome, not an exceptional state.
This page connects to no real server or database. Code samples are illustrative for .NET 8, Next.js and SQL Server; timings are example values in the simulation, not measurements. Try samples only in your own development environment; never share real connection strings, tokens or passwords.
Try it yourself first.
A customer sends a screenshot saying ‘the page failed’; it shows only ‘traceId: 00-4bf92f…’. How do you find the problem?
Show the solution and explanation
Log sisteminde TraceId = 00-4bf92f… ile ara:
hata kaydı, istisna türü, yığın izi, isteğin yolu ve süresi.
Dağıtık izleme varsa aynı kimlikle Next.js ve SQL adımları da görünür.A traceId links a support request to technical records without exposing internals to the user.