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

Comments

@alexdresko
Copy link

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

This comment has been minimized.

Copy link
Owner

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.

@alexdresko

This comment has been minimized.

Copy link
Author

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.

@khellang

This comment has been minimized.

Copy link
Owner

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.

@alexdresko

This comment has been minimized.

Copy link
Author

commented Sep 4, 2019

OKOKOK, I get it now. Thanks!

I referenced this issue from my blog post.

@alexdresko alexdresko closed this Sep 4, 2019

@khellang

This comment has been minimized.

Copy link
Owner

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 😊

@alexdresko

This comment has been minimized.

Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.