This is a rant about how so many apps on many different platforms (TVs, mobile devices, computers, etc...) have decided to not actually show detailed errors any more. Instead, we get something along the lines of:
Oops, somehting went wrong. Please try again later
.... and then, well, we get to figure out what just happened and what in the world we need to do about it. And good luck with that, since you have no idea what just failed.
Why software developers?!? Why have you forsaken us?
EDIT 24 hours later: I feel like I need to clarify a few things:
I've worked for 8 software companies over 30+ years. I know why putting a DB error into the message users see is a bad idea. I know that makes me uncommon, but I still want more info from these messages.
You all are answering as if there are only two ways this can work: (a) what we have now (which is useless), and (b) a detailed error listing showing a full stack trace. I think the developers could meet me half-way.
What I want is either (a) "Something went wrong on the server, you can't fix it, but we will" or (b) "Something on your end didn't work. Check your network or restart the app or do something differently and then try the same thing again". And if they're blocking me because I'm using a VPN, fucking say so (but that's a whole separate thing...)
Some apps do provide enough info so I have a clue what I should do next, and I appreciate the effort they put into helping me. I think what I am really ranting about is I want more developers to take the time to do this instead of reporting all errors with "Oops, try again". (If the error is in their server, why should I try again?) Give me a hint as to the problem, so I have something to go on.
Cheers y'all. Still love you my techy brothers and sisters.
If it's an error code I've worked around before, apply same troubleshooting.
If its a new errror code, search the error code to see how other people solved it.
If no one else has solved the error code, try analogous troubleshooting, post results online with the error code name, successful or not.
I agree with Nouveau_Brunswick here.
And to add: to @hperrin@lemmy.ca , are you not also a user of software and do you not see room for improvement in many apps? That's where I am rn: I just want them to try harder to communicate a tiny bit more info when things go so wrong that a message has to be displayed on my screen. Telling me "There's nothing you can do to fix the problem" would be a big help, for instance. Make sense?
So what you're saying is that your code is garbage and you're hiding it from users because it's too much work to fix it.
If you have 2000 daily people getting error messages, your code is garbage rofl
And if your company would rather you avoid those tickets by not giving out error codes, your company is also garbage. Which to be fair, is a lot of tech companies.
All I'm saying is that the vast majority of "oops" issues happen before step one. Client-side issues. For those, give an error code. All the stuff you talked about, there's little to nothing users can do. And yeah, it could definitely be done better, but it would require abandoning the "ooh shiny new thing" mentality of tech companies. Updates just to boost resumes, deprecation of anything user friendly. It's an endemic cultural problem.
How? I mean how is it possible to send a crash log to the server when the problem is that the client can't connect to the server?
You by definition don't see most of these errors except maybe as pings, depending on why it can't connect
By nature of software consisting of a client and a server, there are certainly errors that can be bypassed on the client side.
Server side software does not mean "there is literally no errors that are dependent on client input." That's ridiculous to think, but pervasive in this comment section it seems.
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.
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 wouldn't know, because it doesn't just tell you directly.
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 the company believes so, then write that part in. 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.
Yes. Bad example. Pick any other number of examples. You can probably put a useful time range.
Already commented on that. They believe it to be so, I don't agree with that choice.
It doesn't have to be either or. Error messages can have a baseline of mild computer knowledge, and stretch up to people who know what they are doing. You can cater to both.
It doesn't have to be utterly useless. Just because you can't fix anything from where you are doesn't mean you can't benefit. If the error is deemed unfixable for customers, give a timeframe of when it should be fixed and the intended course of action (what should they do if its not back up soon and they need it to be up). Useless is a choice, but its also subjective. You may find "Something went wrong. Try again later" as not useless. I deem it so.
Unfounded assertion. I have fixed server-client issues before as the client. Let me repeat it: I have fixed server-client issues as the client. There are of course issues I can't fix
I think our disconnect partly comes from the fact that I am discussing this from a point of view of server operators being fallible. If in theory they always know what is fixable only on the server and never make a mistake in that regard, then we fall back to make a useless error message more useful. But they do make mistakes (or are purposefully hiding information so you don't know how to get around the error). The Linux example. It would be very easy to justify that in the same way that companies could justify a useless error message for something which could actually be fixed. How many people are going to look at the initframfs logs and know how to chroot in, edit the initramfs init script, and then rebuild the cpio and shove it in boot? Probably less than those that don't.
You could use this as a justification to hide it completely, but also harm those that could fix it, and also harm error reporting as the users machines just don't boot the distro. I disagree with this decision.
if that affected ChatGPTs popularity, I couldn't tell.
So I'll round it all off with this: improve the error messages as a whole. Add contact information, time till likely fix, course of action (try again later is vague crap). The messages feel like an unhelpful wall, the error equivalent of a chatbot responding to your pleads for support. Also, you might not always be correct in whether something is fixable or not. You could add the detailed error information near the bottom, if people don't need it then no harm. If people do then its useful. Not adding it and then it being of use could be worse than adding it and it just never being necessary.
I think this topic is wrung out dry.