Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

return BadRequest(); vs return BadRequest(something);. #65

Closed
alexdresko opened this issue Sep 3, 2019 · 7 comments
Closed

return BadRequest(); vs return BadRequest(something);. #65

alexdresko opened this issue Sep 3, 2019 · 7 comments

Comments

@alexdresko
Copy link

@alexdresko alexdresko commented Sep 3, 2019

This is probably more of a .NET team question, but you seem to be the expert. :)

I'm curious why return BadRequest(); returns problem details, but return BadRequest(something); returns whatever is passed in. Obviously, you can derive something from ProblemDetails and pass that in, but that seems overly complicated. I wish return BadRequest(something); would always return problem details.

Thoughts?

@khellang
Copy link
Owner

@khellang khellang commented Sep 3, 2019

But why would you pass something, without something deriving from ProblemDetails if you really want problem details?

The technical reason why it doesn't work is because MVC will serialize something and write it to the body, before the response gets back to the middleware. At that point it's too late for the middleware to start writing.

Loading

@alexdresko
Copy link
Author

@alexdresko alexdresko commented Sep 4, 2019

But why would you pass something, without something deriving from ProblemDetails if you really want problem details?

Typically to return additional information about the error. For example, with return NotFound(...), you can include the ID of the record that was not found.

public ActionResult Something(int id)
{
    // if the record can't be found in the database
    return NotFound(id);
}

It doesn't make sense that one overload of NotFound would act differently from another.

Loading

@khellang
Copy link
Owner

@khellang khellang commented Sep 4, 2019

It doesn't make sense that one overload of NotFound would act differently from another.

When you know that once you write to the body stream, it's flushed to the client and no other MW can write to it, it makes sense; one overload contains a body, the other doesn't.

Loading

@alexdresko
Copy link
Author

@alexdresko alexdresko commented Sep 4, 2019

OKOKOK, I get it now. Thanks!

I referenced this issue from my blog post.

Loading

@alexdresko alexdresko closed this Sep 4, 2019
@khellang
Copy link
Owner

@khellang khellang commented Sep 4, 2019

Nice post! 👏

Yeah, I agree that it needs a bit of intimate knowledge of how MVC and middleware works together og what MVC actually does when returning different results. You could probably write some MVC filters to tweak the behaviors, but I wanted a lower level middleware that works (more or less) without MVC.

BTW, when throwing a ProblemDetailsException, you can still avoid the (default) 500 status code by setting the ProblemDetails.Status property 😊

Loading

@alexdresko
Copy link
Author

@alexdresko alexdresko commented Sep 5, 2019

BTW, when throwing a ProblemDetailsException, you can still avoid the (default) 500 status code by setting the ProblemDetails.Status property 😊

I'll be honest, I can't figure out how to do this. Can you point me an an example or doc?

Also, I updated the post to this information that was just released with .NET Core 3 Preview 9:

image

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants