Re:Browsers barely care what HTTP status code your web pages...
by kube-system on Friday August 11, 2023 @02:51PM
(#37092400)
This is probably not the result of internationally dumbing down the message, but lazy error handling.
Re:Browsers barely care what HTTP status code your web pages...
by pomstazlesa on Friday August 11, 2023 @06:08PM
(#37094662)
It's probably both. Since you want to obscure it from the end user, you can also afford to be lazy and have sloppy implementation.
Re:Browsers barely care what HTTP status code your web pages...
by Guvante on Saturday August 12, 2023 @02:56AM
(#37097729)
That isn't true, laziness will punch straight through a tight definition of error code handling.
After all if you have three API layers realizing in this situation the second layer isn't forwarding that error code because it erroneously thought it was one you hide behind a generic one is pretty common.
Re:Browsers barely care what HTTP status code your web pages...
by WirelessGigabit on Friday August 11, 2023 @06:52PM
(#37095033)
This is just a general try catch. Build happy path, get VC money and deploy. We'll fix it later.
I was trying to place an order, and it kept failing with a red banner stating "something went wrong" (I'm paraphrasing as I don't recall the exact verbage, but it was one of those completely worthless error messages)
Pop open dev tools ... the server is returning something about a graphql error.
Support had no idea what was wrong.
The problem ended up being that my saved credit card had expired. For fuck's sake, that is a user-actionable error; tell me what the problem is. At least tell me it was a payment problem, since that's probably all the payment processor told you.