5 ms·
It's somewhat fair though. If there's a case that would cause errors for the system and it's a case that you're not supposed to handle, then a 400 error sounds
by xmprt 2y ago
It's somewhat fair though. If there's a case that would cause errors for the system and it's a case that you're not supposed to handle, then a 400 error sounds perfect for that case. For example, if you have a service and it panics/returns 500 when you pass in an empty user id, then you could instead return a 400 before you hit the panic and all is good.
- bb88 2y agoNormally you should attempt to find all the corner cases and present the errors to the user -- before processing the request. If you can't do this, it's time to rethink how your api works. A good api is simple to use and simple to write. It also simplifies your business logic in that all the possible user defined idiocies are caught before your business logic actually processes the request. Some frameworks do this better than others. And rather than documentation, I tend to prefer comprehensive error messages.
- fmbb 2y ago> Normally you should attempt to find all the corner cases and present the errors to the user -- before processing the request. That is what they are suggesting. You check the request and return 400 if it’s bad.
- bb88 2y agoOne example of a 500 error is a null pointer error. Was it a bad request or a logic error? One is your problem the other is not. Just returning a 400 hides that issue. Validating the payload before processing it simplifies the issue for everyone involved. A 500 error should be your problem with a stack trace in the log. A 400 error should provide enough description to tell the user it's theirs and how to fix it. Just marking recoding a 500 to a 400 because of a null pointer error would get noticed on a code review and marked up on a code review.
- bdangubic 2y ago400 - you fucked up 500 - we fucked up