Been having similar case with dev teams who have coded every error to be 500. User typed the wrong URL? 500. User tried to access a page without logging in? 500… Makes detecting real errors a pain
I’d easily take that over ‘200 for everything’. If at least errors are distinct from success, I’d take that as a win. My standards have been lowered by so many ‘200 for everything’ backends…
And on the other side of this are JS devs that check for neither error response codes or error messages, and write an error into their own data as if it’s the result they were after.
Always fun to see GET /orders/{error : “invalid branchID provided”} in your logs.
I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.
I’m not a web dev, but had a similar problem with a niche compiler I used to develop.
We were pretty good at validating invariants at the mid and back-end. This meant that most user errors got reported as internal errors. Generally, these errors were good enough that users were able to get used to reading them and fix their code.
It was next to impossible to actually get users to file bugs about this. Our internal error messages started with a banner that read “THIS IS A BUG IN <compiler name>. PLEASE REPORT TO <support email address>”. Despite that, whenever we actually got a bug report, it would inevitably start with “I’m pretty sure this isn’t actually a bug in the compiler, but I can’t figure out what I am doing wrong in my code”.
I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.
That’s certainly an unusual take. If you are a backend to HTTP and something throws a completely bogus URL out of left field at you, that’s not by any means a backend error.
I guess your take is that it might be some sort of usability issue or such because if 95% of clients try to hit the same non-existant URL, that probably means there’s some reasonable expectation that you should do something about the URL. However that’s relatively more rare a sort of ‘invalid URL’ scenario. The vast vast majority are some sort of scanners trying bogus crap, followed by an impossibly diverse set of typos and peculiar one-off assumptions that you can’t possibly reasonably cover.
If it’s not a backend error, you shouldn’t be throwing a 5xx error code. Since you are throwing a 500, you have a server bug; even if that bug is simply “sends incorrect error code”
Been having similar case with dev teams who have coded every error to be 500. User typed the wrong URL? 500. User tried to access a page without logging in? 500… Makes detecting real errors a pain
Makes all issues their problem. Clearly it’s not a 4xx error so not something the client did wrong.
I’d easily take that over ‘200 for everything’. If at least errors are distinct from success, I’d take that as a win. My standards have been lowered by so many ‘200 for everything’ backends…
And on the other side of this are JS devs that check for neither error response codes or error messages, and write an error into their own data as if it’s the result they were after.
Always fun to see GET /orders/{error : “invalid branchID provided”} in your logs.
I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.
I’m not a web dev, but had a similar problem with a niche compiler I used to develop.
We were pretty good at validating invariants at the mid and back-end. This meant that most user errors got reported as internal errors. Generally, these errors were good enough that users were able to get used to reading them and fix their code.
It was next to impossible to actually get users to file bugs about this. Our internal error messages started with a banner that read “THIS IS A BUG IN <compiler name>. PLEASE REPORT TO <support email address>”. Despite that, whenever we actually got a bug report, it would inevitably start with “I’m pretty sure this isn’t actually a bug in the compiler, but I can’t figure out what I am doing wrong in my code”.
That’s certainly an unusual take. If you are a backend to HTTP and something throws a completely bogus URL out of left field at you, that’s not by any means a backend error.
I guess your take is that it might be some sort of usability issue or such because if 95% of clients try to hit the same non-existant URL, that probably means there’s some reasonable expectation that you should do something about the URL. However that’s relatively more rare a sort of ‘invalid URL’ scenario. The vast vast majority are some sort of scanners trying bogus crap, followed by an impossibly diverse set of typos and peculiar one-off assumptions that you can’t possibly reasonably cover.
If it’s not a backend error, you shouldn’t be throwing a 5xx error code. Since you are throwing a 500, you have a server bug; even if that bug is simply “sends incorrect error code”
Ok, got you, thought you were saying a bad url from client was inherently a backend mistake.