[flagged]
When life gives you lemons, write better error messages
21–30 of 72 posts
Re: When life gives you lemons, write better error messages
#22Earlier quoted context omitted.
Agreed, but you can have both. A simple error for the user to understand, and a click for more details that spits out all the troubleshooting information.
It depends. If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly. “Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
> If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user.
What support team? The ones that were all not hired in the first place, and if they were hired then they were replaced by AI? The same support team that customers simply cannot reach at all?
Sounds very useful.
Re: When life gives you lemons, write better error messages
#23Earlier quoted context omitted.
It depends. If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly. “Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
I have approximately zero confidence that if I see an error message that says "our support team received the error" that anyone has received the error. In fact I would generally bet thousands of dollars against that.
Eh, depends.
I very much believe this gets dumped in some kind of ELK stack or something like that. And quite often teams will monitor to ensure that some new error message isn't going wild and alerts are sent out.
Single errors mean nothing, unless of course you're putting in a support call and we're directly looking it up.
Re: When life gives you lemons, write better error messages
#24Earlier quoted context omitted.
Depends on exactly the situation- when I worked on a very expensive desktop application years ago I was warned about giving too much information in error messages as it might help crackers. With how powerful Ghidra is now, I'm not sure that it matters much any more.
This is security through obscurity -- can complement other methods but won't do much for you against competent adversaries.
Anyone can access the web interface including attackers, so don't dump debug information there. Feel free to put the errors behind an admin interface or to local files that can be retrived.
Re: When life gives you lemons, write better error messages
#25Long ago, I had the insight that not all users are equally technically proficient. Some had the chops to fix some problems if given sufficient information. Other users would be confused with too much detail.
I was writing code for AT&T (in the 1980s), and we were our own customer. So I wrote the error routines to check an environment variable and provide different error messages for different types of users: developers, testers, and a few power users got very detailed error messages, ordinary users got friendly, simplified messages (and weren't told about the environment variable).
Re: When life gives you lemons, write better error messages
#26Error: File not found Which file?!?!?! Anyway, I disagree strongly on the technical jargon. Ok, if it's not really an error and the user can retry or similar sure. But if it's bad times, an exception or similar, don't care about the user. Instead include as much detail as you need. A non-technical user won't be able to do anything anyway, and a sanitized error message means support or a technical user has a much hard…
IMO if you show an error to end users it needs to be actionable. Tell them what to do instead (e.g retry or wait, use other input file, etc etc).
So don't say "InvalidArgumentException xyz", say "Expected a number but got 'hello'".
This doesn't always work, but essentially hide tech details from users. If you must, include a bit of extra information (a request number or whatever) that helps you log dive.
Re: When life gives you lemons, write better error messages
#27Earlier quoted context omitted.
It depends. If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly. “Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
I have approximately zero confidence that if I see an error message that says "our support team received the error" that anyone has received the error. In fact I would generally bet thousands of dollars against that.
That depends. There are common errors where the support team gets that information because they have seen it before and having seen that error changes the support script in a hopefully helpful way.
Companies generally have massive amounts of errors though. They investigate the most common errors for their script. Sometimes when someone figures out a different error they adjust the script. Most errors though never get investigated.
Re: When life gives you lemons, write better error messages
#28I fail to understand why "Try again later" is considered bad because "Generic", but "Please try connecting again" is good because it's "Help them fix it". Likewise, it says "You changes were saved" is good because it "provides reassurance", but is it true ? The next sentence is "but we could not connect to your account", which could very well mean that the request didn't go through and the changes weren't saved. There's no way of knowing.
Re: When life gives you lemons, write better error messages
#29I fail to understand why "Try again later" is considered bad because "Generic", but "Please try connecting again" is good because it's "Help them fix it". Likewise, it says "You changes were saved" is good because it "provides reassurance", but is it true ? The next sentence is "but we could not connect to your account", which could very well mean that the request didn't go through and the changes weren't saved. Ther…
Had the exact same thoughts.
* I thought at first they meant "later" was too vague, but omitting the word only makes the message more terse, not more specific. It's as if they decided ahead of time that the old message was bad and embodies certain qualities (which they highlighted) and the new was good and embodies certain other qualities (also highlighted), and they didn't bother to rethink the new one after seeing almost the same phrase used as examples of bad and good.
* "Your changes were saved": yeah, if the change is connecting your account to a third-party service, and they were unable to connect...did they save the intent to connect? How do you resume it? Or was this part of a greater set of changes? The reassurance works best if it's consistently true, but I'm doubtful.
Re: When life gives you lemons, write better error messages
#30Earlier quoted context omitted.
It depends. If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. User should get “our support team received the error” and support should handle it directly. “Something went wrong, try again later” is also acceptable but only if support team gets info about it and user really ca just try later.
> If you’re SaaS vendor you should give troubleshooting information to your support team skipping the user. What support team? The ones that were all not hired in the first place, and if they were hired then they were replaced by AI? The same support team that customers simply cannot reach at all? Sounds very useful.
Not everyone is Google, Meta, Amazon or Microsoft.
There are companies that care about their customers.