ExceptionHandlerMiddleware will throw original exception if exception handler cannot be found #434
Labels
5.0.0
Announcements related to ASP.NET Core 5.0
Announcement
Breaking change
Documented
The breaking change has been published to the .NET Core docs
ExceptionHandlerMiddleware will throw original exception if exception handler cannot be found
Currently, the
ExceptionHandlerMiddleware
will execute the configured exception handler when an exception has occurred. If the exception handler, configured viaExceptionHandlerOptions.ExceptionHandlingPath
for example, cannot be found, a 404 response will be produced. The 404 error is especially misleading since it makes it seem like an user error and obscures the fact that an exception occurred on the server.To resolve this, the default behavior of
ExceptionHandlerMiddleware
will now throw the original exception if the exception handler could not be found. As a result, a 500 response will be produced by the server and it will be more obvious to examine the server logs when debugging the error that occurred.Version introduced
ASP.NET Core 5.0 RC 1
Old behavior
The
ExceptionHandlerMiddleware
will currently produce a 404 error response when the configured exception handler could not be found when the middleware executes.New behavior
By default, the
ExceptionHandlerMiddleware
will now throw the original exception when the configured exception handler could not be found (i.e. the exception handler returns a 404) when the middleware executes. To allow 404 responses to be returned by the exception handler, please configure the optionAllowStatusCode404Response
onExceptionHandlerOptions
totrue
. When this option is set to true, the current behavior is maintained.Reason for change
We have often seen
ExceptionHandlerMiddleware
with misconfigured handlers producing 404 responses leading to confusion since the 404 error doesn't make it obvious an exception occurred on the server. This change is made so that a 500 error will be produced instead to make it more obvious that it's not caused by user error but rather an exception was encountered on the server.Recommended action
There is no API change due to this breaking change so all existing apps will continue to compile and run. The exception thrown will be handled by the server. For example, the exception will be converted to a 500 error response by Kestrel HTTP server or HTTP.SYS server.
For backwards compatibility using the current behavior, where a 404 response from the exception handler is allowed, please set
AllowStatusCode404Response
onExceptionHandlerOptions
totrue
. See "New behavior" section for details.Category
ASP.NET
Affected APIs
"Not detectable via API analysis"
Issue metadata
See discussion at: dotnet/aspnetcore#25288
The text was updated successfully, but these errors were encountered: