Expected invalid input and unexpected server failure need different responses. A client can correct an empty title. It cannot correct a server exception by guessing from a stack trace. Problem Details gives APIs a standard shape for describing errors.

These .NET Core interview questions use a local fictional article endpoint on ASP.NET Core 10. It has no database writes. The failure endpoint deliberately throws so you can inspect the production error boundary.

How can a small API distinguish the paths?

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddProblemDetails();
var app = builder.Build();
app.UseExceptionHandler();
app.UseStatusCodePages();

app.MapPost("/articles/preview", (PreviewRequest request) =>
    string.IsNullOrWhiteSpace(request.Title)
        ? Results.ValidationProblem(new Dictionary<string, string[]>
          { ["title"] = ["Enter a title."] })
        : Results.Ok(new { title = request.Title.Trim() }));
app.MapGet("/simulate-failure", () =>
    Task.FromException<IResult>(new InvalidOperationException("Sample failure")));
app.Run();

record PreviewRequest(string? Title);

Post a JSON object with an empty title and request JSON back. The endpoint returns validation information with a 400 status. The deliberate failure should produce a server-error response through the configured handler. Test it outside Development to inspect production behavior.

What should the response contain?

A useful public error identifies the problem category, a safe explanation and the relevant status. Field validation can identify the field and a correction. A trace identifier can help support staff find the corresponding server log without exposing internal details.

Do not put connection strings, SQL text containing private data or raw exception stacks into public detail fields. Keep diagnostic context in access-controlled logs. A message such as “could not complete the request” is safer than disclosing a dependency's raw exception.

Does AddProblemDetails rewrite every response?

No. Middleware, explicit endpoint results and content negotiation affect what is written. AddProblemDetails registers services used by supported error-handling paths. It is not a promise that every manually written body becomes a Problem Details document.

Send an appropriate Accept header in tests, inspect the content type and parse the actual body. Do not assert only that a string contains “error.” Custom writers and framework configuration can change the response format.

Which HTTP status should you choose?

Use the meaning of the failure. Invalid input commonly uses 400. A missing resource uses 404. An unauthenticated caller and an authenticated caller without access need distinct authentication and authorization handling. A state conflict can justify 409. Unexpected server failures belong in the 5xx class.

Do not return 200 with an error body merely to simplify the frontend. Monitoring, caches and clients rely on the status. Equally, do not classify every rejected business operation as an unexpected exception.

How would you test the boundary?

  • Valid input gets the expected success shape.
  • Invalid title gets a field error and 400.
  • The simulated exception gets a safe 500 response.
  • An unknown route returns the intended 404 representation.
  • Logs contain correlation context without exposing it as a secret.

A failure after response headers have started needs special consideration: the middleware cannot always replace a partially written response with a new document.

Practice a clear explanation

Describe the expected failure first, then the boundary for unexpected errors, then how the caller can recover. Error handling is complete only when the response, diagnostics and client behavior agree.

References and next practice

learn.microsoft.com — net errors · developer.mozilla.org — http

dotnet question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud