At a previous job, writing unambiguous error messages was discouraged. Everything just had to be "Oops! Something went wrong"
The reasoning was that "users can't do anything with information we tell them anyways", despite the overwhelming number of help desk tickets we'd get from "Oops!" appearing in a million different scenarios with no clear way for us to tell what error actually caused the message to appear.
Users naturally report the messages that they see because they're helping us to see the problem. I didn't get why that was such a hard concept to understand
That seems like peak uselessness. Even "Error code 0x00ad4829" is a more useful message, because even if it's useless to the user it is useful to somebody.
There is some logic, the "you don't want to expose your internals". Really useful messages might contain a lot of details about the tech stack you use (giving a nice hint into which CVEs to try).
That said, this is an easily solved problem. The best solution is to aggressively log errors AND prioritize having dev teams push that error count to 0. If an error happens, it's a bug.
The next way to solve it is simply a report button. Let the users click a "I'm mad at you for not working" button and embed something like a session ID that allows internal queries into what went wrong.
Error codes are a terrible solution, but perhaps an OK option if this is not hosted software. That said, a more user friendly approach would be a QR code with all the relevant details embedded.
> Really useful messages might contain a lot of details about the tech stack you use (giving a nice hint into which CVEs to try).
Nope. Useful messages contain details about what your software does. Anything about your tech stack is redundant and can be removed.
> The best solution is to aggressively log errors AND prioritize having dev teams push that error count to 0.
Many errors can only be replicated talking to users. And on the cases your dev team is not all capable enough to remove all errors, you will still want to provide customer support and work-arounds.
> The next way to solve it is simply a report button.
A report button is good. But neither session ID nor any data that you can reasonably add to your logs will be enough to let dev know what went wrong. Besides, your report button will have errors too.
And anyway, anything that you said applies exclusively to people that create web applications. Many other types of application exist, and everybody writing them are better off not following any of your recommendations.
Why are error codes a terrible solution? I rather have an error "bad request f12793b2" than a "bad request". Obviously I prefer a "bad request, 'expiresAt cannot be after 2022-12-19'. Code f12793b2".
Having a unique ID to be able to search in documentation or even source code is -IMO- preferable. It's still rather technical and helps only those who can search such docs, but at least it gives something unique to google/search for."
Until one day you find some random dev is logging failed authentication attempts and including the email and password in the logs…
(and the most amusing part of that incident was tracing down the offender by finding the earliest of those particular log lines, and getting his real email address password out of them… “Hey Phil, what’s ‘Dragons87!’?” “Ummm, what? That’s, errr, my gsuite password. How did you know?”)
This seems to be the approach that Android takes. If you try to connect to a WiFi network and it fails, it just gives up. It won't tell you why it failed. This makes it very frustrating to figure out what's wrong. Maybe I wouldn't understand the error message, but at least it would provide a starting place for me to look up more information or ask for help from someone knowledgable.
> The reasoning was that "users can't do anything with information we tell them anyways",
I mean, I feel like the focus of the OP was on giving them something they could do something with. Like the information that their information was not lost; and the recommendation to change X or try again in Y way; and the fallthrough to contact customer support with a quick link.
The OP was definitely not recommending giving more specific technical info without thinking about what the user could do with it, but instead specifically thinking about what hte user could do or would want to know (about their data/account, not about your under the hood services), and giving info to that end.
I have only worked at one place that wanted informative error messages.
All the others wanted to hide the reason because "if we know the reason and tell the user, we seem incompetent" or "then hackers will know which API call isn't working right" (apparently the network console in Chrome is beyond hackers) to wanting customers to be dependent as they paid for support.
The error user see and the one you log shouldn't be the same, you still can log complete information about an error, while the user will see only "Oops, something went wrong"
As long as you are logging the error with the context somewhere that's fine. You could always include a timestamp or request ID with the user message to not give away information, but be able to easily search your logs for the occurrence.
The reasoning was that "users can't do anything with information we tell them anyways", despite the overwhelming number of help desk tickets we'd get from "Oops!" appearing in a million different scenarios with no clear way for us to tell what error actually caused the message to appear.
Users naturally report the messages that they see because they're helping us to see the problem. I didn't get why that was such a hard concept to understand