Comment on Oops, something went wrong!
unhrpetby@sh.itjust.works 10 hours agoThese error messages never (sic) used on data validation issues.
You are incorrect. I have had issues that were exactly that. Such as a password that was failing to be accepted and then giving generic error responses, which I then had to trial-and-error brute force to find which part of my password they weren’t allowing on the backend.
You stance might become easier to defend if you avoid absolutes.
hperrin@lemmy.ca 10 hours ago
Read the next sentence.
unhrpetby@sh.itjust.works 9 hours ago
The error is unnecessarily vague.
If the message is supposed to mean “There is an internal error that is of little use to you, so you can only wait while we fix it. Try again in 10 minutes.” Then say that. That tells me a developer made a conscious decision to classify the failure mode as one which I cannot fix. They are explaining to you what type of error they perceive it to be.
Instead we have “Something went wrong. Try again later.” which doesn’t say that directly. This could just be them designing their systems as though every user is incompetent, and denying you the information to fix the issue yourself.
You would never know, because it doesn’t just tell you directly.
hperrin@lemmy.ca 9 hours ago
It is intentionally and, I would argue, necessarily vague.
First, there is no time frame for these kinds of errors. If it’s just a cache host that’s down, you could retry right now and the load balancer would probably have taken that host out of rotation already. If it’s a primary db that’s down, that may take 5 minutes. If there’s no replica to promote, it might take 30 minutes. If the whole db layer is down, it might take an hour or two. If an entire release needs to be rolled back, it might take a couple hours. There are just too many scenarios and too many variables to give a useful time frame.
Second, you might appreciate an error message like that, but these error messages aren’t written for you and they’re usually not even written by developers. They’re written by designers and translated into many languages. They need to be concise, easily understood, and not easily construed as derogatory or malicious in any language. They are written for the broadest audience. You are not the broadest audience.
Third, we have to design systems as if every user is incompetent and/or malicious, because many of them are. Let me give you an example. I once got an email from another engineer using an internal system my team wrote. He said, “hey I’m getting this error, can you help?” He attached a screenshot showing an error message that read, “Your auth token has expired. Please refresh the page.” He was a senior engineer.
Fourth, and I cannot stress this enough, there is almost always nothing you can do when you hit an error like this. Any information given to you for the vast majority of these kinds of errors would be entirely useless to you. You cannot promote a db shard yourself. You cannot bring up a cache host yourself. You cannot take a host out of load balancer rotation yourself. The only reason this information could possibly benefit you is to satisfy your curiosity.
unhrpetby@sh.itjust.works 8 hours ago
If I was are able to isolate the issue to, for example, expired certs, I could absolutely give you a ballpark answer on how long it should take/when it might be back up. It doesn’t need to be very precise, but I have accessed websites only to be shown an error with zero idea whether this is a multi-day event or something I can wait five minutes and it be fixed.
Cooperation with a developer would help here.
If you write only for a child, your usefulness ceiling is that of what a child could understand. You could have your obvious boilerplate message, and then under that provide more information.
I feel as if this is a simple problem to avoid.
See the bottom of this post
If so, then write that part it. Otherwise, it isn’t stated that such is the case. It would be one more sentence on the boilerplate section.
Overall this has to do with what you are optimizing for. Its clear to me that many businesses believe useless boilerplate error messages are most cost effective. If you want to be most cost-effective, then cutting corners on the error messages likely saves time with few financial downsides. But It doesn’t have to be this way.
Designing systems for the lowest person on the totem poll isn’t without downsides. I have used Linux systems that made the bootup hide all log messages. This means that people that can actually fix a broken system using the logs, are going to have a harder time, as you just hid away all the moving parts and complexity from the end user. Some machines I wouldn’t have been able to fix were it not for the detailed logs.
Or we could talk about privacy. Nearly everyone can use a computer. Great right!? But how many people actually understand the privacy implications of using a machine that is controlled by a closed source corporation. Of entering load of data into that machine? Very few.
You can design a system for idiots. But you don’t have to. There are things in life that have prerequisites. If someone comes over to my computer and asks “What’s that” on a kernel log output, I’ll ask them, “Do you know what a kernel is”. If they don’t, then I will tell them not to worry about it. My explanations are not for everyone. Neither are my software.