Problem details /2 #27009
Problem details /2 #27009
Conversation
Public review of the doc build:
Client error response |
Thanks @Rick-Anderson 😅, but I wasn't able to see how the problem was resolved since the controller writes the problem details to stream before the middleware handles it. Since there is no way around it than changing the controller like this:
Should I leave the code in the issue as it is since you explained why in the post? |
No, do a PR and create a 3rd controller named |
I can only see one controller from my end or am I mistaken? |
|
2 controllers, one file. Put the 3rd controller in the same file. |
Ooh I need to pull, I don't have this locally 😅 |
Never do a PR from your old branch. |
Sure thanks |
Co-authored-by: Tom Dykstra <[email protected]>
There was a problem hiding this comment.
Looks good! I have some suggestions. Also, not directly related to your changes but will be great if we could:
- Remove this topic
## Custom Middleware to handle exceptions Update Produce a ProblemDetails payload for exceptionsto keep mentioning the community middleware as an addition to what we have now.
|
The sample app dead wood |
Does "dead wood" mean something special here? 😂 |
Co-authored-by: Bruno Oliveira <[email protected]>
There was a problem hiding this comment.
@brunolins16 start at Internal review URL
sample code
I changed it to say
The automatic creation of a ProblemDetails for error status codes is enabled by default, but error responses can be configured in one of the following ways:
Then I added a new section just below
Default problem details response
I think I responded to most of your suggestions. Let me know what else. We might need to do a 15 minute teams meeting.
aspnetcore/web-api/handle-errors.md
Outdated
| ### Produce a ProblemDetails payload for exceptions | ||
|
|
||
| ASP.NET Core doesn't produce a standardized error payload when an unhandled exception occurs. For scenarios where it's desirable to return a standardized [ProblemDetails response](https://datatracker.ietf.org/doc/html/rfc7807) to the client, the [ProblemDetails middleware](https://www.nuget.org/packages/Hellang.Middleware.ProblemDetails/) can be used to map exceptions and 404 responses to a [ProblemDetails](xref:web-api/handle-errors#pd) payload. The exception handling middleware can also be used to return a <xref:Microsoft.AspNetCore.Mvc.ProblemDetails> payload for unhandled exceptions. | ||
|
|
||
| <!-- TODO UPDATE • Update Produce a ProblemDetails payload for exceptions to keep mentioning the community middleware as an addition to what we have now.--> |
There was a problem hiding this comment.
Update
Produce a ProblemDetails payload for exceptionsto keep mentioning the community middleware as an addition to what we have now.
@brunolins16 what updates are needed?
There was a problem hiding this comment.
@Rick-Anderson This statement is not true ASP.NET Core doesn't produce a standardized error payload when an unhandled exception occurs. For scenarios where it's desirable to return a standardized [ProblemDetails response] anymore. Maybe we can update to say that with the AddProblemDetails + middleware (StatusCodeMiddleware and ExceptionHandlerMiddleware) we will produce the ProblemDetails response but they can continue using the ProblemDetails middleware or configure manually the ExceptionHandler to write the PR. make sense?
There was a problem hiding this comment.
@brunolins16 can you take a quick look at Produce a ProblemDetails payload for exceptions ?
There was a problem hiding this comment.
LGTM. I have feedback about one single statement but other than that it is pretty good.
aspnetcore/web-api/handle-errors.md
Outdated
| } | ||
| ``` | ||
|
|
||
| For most apps, the preceding code is all that is needed as unhandled exceptions are rare. |
There was a problem hiding this comment.
@brunolins16 can I stay that? All that's needed?
There was a problem hiding this comment.
Do you mean the sample code? If yes, the lines that you need to highlight for a non-dev environment are:
builder.Services.AddProblemDetails();app.UseExceptionHandler();There was a problem hiding this comment.
I am not sure why exactly, but this statement does not sound good to me For most apps, the preceding code is all that is needed as unhandled exceptions are rare. Maybe you could say something like For most apps, the preceding code is all that is needed, however, if you want to customize [point to the customization topic]
|
|
||
| For most apps, the preceding code is all that is needed as unhandled exceptions are rare. | ||
|
|
||
| An alternative to a [custom exception handler page](xref:fundamentals/error-handling#exception-handler-page) is to provide a lambda to <xref:Microsoft.AspNetCore.Builder.ExceptionHandlerExtensions.UseExceptionHandler%2A>. Using a lambda allows access to the error and writing a problem details response with [`IProblemDetailsService.WriteAsync`](/dotnet/api/microsoft.aspnetcore.http.iproblemdetailsservice.writeasync?view=aspnetcore-7.0&preserve-view=true): |
There was a problem hiding this comment.
What is the strategy for to content duplication?
contributes to #26685
Fixes #25107
Internal review URL
sample code
Add Diagnostics middleware updates to What's new