RequestDelegateFactory should throw BadHttpRequestException when in development to make diagnosing handler issues easier

[DamianEdwards]

When using the new "Map*" methods to build minimal APIs via the RouteDelegateFactory, it can be difficult to diagnose the cause of 400 and 415 responses that are implicitly returned when the mapped route handler's parameters cannot be satisfied from the request, either via the implicit parameter binding behavior or TryParse' and 'BindAsync methods on the parameter target types.

It would be helpful if when in development (i.e. Environment.IsDevelopment() == true) instead of implicitly returning the response with a 4xx status code, a BadHttpRequestException was thrown instead, with the relevant status code set and an appropriate exception message added, making it clear why the exception/status code is being throw/set. With the DeveloperExceptionPageMiddleware on (which it is by default in development in .NET 6 when using WebApplication) the exception message and stack trace will be returned in the response body, making it much clearer why the invocation of the route handler failed.

This behavior should be controllable via a new options type RouteHandlerOptions with boolean property ThrowOnBadRequest that is configured by default to be true when Environment.IsDevelopmet() is true. The default configuration would be achieved via an internal type implementing IConfigureOptions<RouteHandlerOptions> that is registered in DI when IServiceCollection.AddRouting() is called.

Related:

• RequestDelegateFactory should return "415 Unsupported Media Type" response when parameter binding and the request isn't JSON #35856
• DeveloperExceptionPageMiddleware should set response status code from BadHttpRequestException #35857

Proposed APIs

namespace Microsoft.AspNetCore.Routing
{
+    public class RouteHandlerOptions
+    {
+        public bool ThrowOnBadRequest { get; set; }
+    }
}

namespace Microsoft.AspNetCore.Http
{
    public class RequestDelegateFactoryOptions
    {
+        public bool ThrowOnBadRequest { get; init; }
    }
}

Example usage

var builder = WebApplication.CreateBuilder(args);

// Enable exceptions for implicit 4xx responses in custom "LocalDev" environment
var isDev = app.Environment.IsDevelopment() || app.Environment.IsEnvironemnt("LocalDev");
builder.Services.Configure<RouteHandlerOptions>(options => options.ThrowOnBadRequest = isDev);

var app = builder.Build();

[martincostello]

This would definitely be helpful. I was working on something today with an rc.1 build and a couple of times managed to forget to make an optional parameter nullable (string vs string?) and had to resort to putting the log level up to Debug on RequestDelegateFactory to see where I’d gone wrong.

[DamianEdwards]

@martincostello yep same here. We discussed changing the log message level dynamically but @halter73's suggestion of throwing ultimately led to this design which I think is much nicer.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.