Provide in-the-box handling for page vs. API errors

[breyed]

Currently, a fair amount of configuration is required to report errors in a native format for pages vs. web API. It would be nice to have the following features:

• A way to tell MVC what routes go to pages vs. APIs.
• Automatic response of HTML error pages for page routes, and empty-or-JSON bodies for API routes.
• Inclusion of status codes from exceptions in API responses (avoids the need to always use IActionResult, which minimizes friction in unit testing web API methods).
• Automatic suppression of authentication redirects for API routes.

Currently, I provide these features like this (and like this for redirects, but it seems like something that would be quite useful to have baked in from the start.

[Tratcher]

Content-negotiation could be used rather than routing to determine the acceptable output formatting for errors.

The HTML vs JSON request is related to #346, but it sounds like you want something for production rather than development.

Mapping exceptions to status codes is precarious. The error handling should only be used for un-expected failures which makes any built-in mapping futile. Expected errors with specific response should be handled in the APIs themselves. You may be able to at least share the logic for handling specific types of errors across APIs using MVC filters. Did you have something more specific in mind?

Auth is a very different feature set from diagnostics. We're working on the redirect problem over in the Security repo with the new virtual handlers. Let's not discuss auth on this thread.

[breyed]

Great points. Content-negotiation is better than path for determining the format. If the MVC formatting provided a way to not only auto-format as JSON and XML, but also as HTML, it would become trivial to write an Error controller (or Razor Page) that handled all formats needed for production error reporting.

Regarding exceptions, they can be just as deterministic as NotFound(), Forbid(), etc. Those methods in ControllerBase rely on clearly documented semantics for the status code. An exception that takes a status code in its constructor can do likewise. It would provide an alternative control flow with identical result.

The nice thing about an exception-based flow is that tests for success scenarios don't need the Assert.IsType checks of the recommended pattern, because the controller method returns the data object directly. For cases where success tests highly outnumber failure tests, this is a nice friction reducer in writing the tests.

[Tratcher]

@rynowak about auto formatting HTML vs XML/JSON.

Exception based flow control is strongly discouraged and we do not design for it here. These diagnostic components are built to provide a minimal fallback experience in the event of an unexpected failure.

[rynowak]

These diagnostic components are built to provide a minimal fallback experience in the event of an unexpected failure.

We've had repeated requests for an experience exactly like this using JSON as the output. We haven't really dug into exactly what we'd do, but this is coming from a real place.

[aspnet-hello]

This issue was moved to dotnet/aspnetcore#2573