If I had a LLM generate fake HN headlines, this would be one of them. Let's do better guys.
When life gives you lemons, write better error messages
41–50 of 72 posts
Re: When life gives you lemons, write better error messages
#42If I had a LLM generate fake HN headlines, this would be one of them. Let's do better guys.
[dead]
Re: When life gives you lemons, write better error messages
#43Error: 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.
expected what to be a number?
what i have is a string. how do i turn my string into a relevant number?
Re: When life gives you lemons, write better error messages
#44Hopefully this becomes a reversal in the trend of giving less and less context to the user. I'm not against the considerations of the article regarding the user and its state of mind, but please do add as much technical detail as possible! Even if an error message is a cryptic error code, that's better than a "Something went wrong" message. This is not better, or even friendlier, UX. An error code can be referenced,…
If it's something I can fix as the user, I need good clear information.
If it's not something I can fix as the user, weigh the options: do I even need to know there's an error? Can you just cache the operation and try again later? Maybe an indication that it's happening in the background?
Current favorite peeve: Uber Driver app for deliveries complains "couldn't upload the photo" of the drop off. It's because this customer lives somewhere off the signal map. I can't do anything about it until I drive a mile back in the other direction. So, instead of blocking further operation, just hold that pic until we get back to civilization, ok? I need the map to get to the next pick up or dropoff, and this nonsense is in the way.
Re: When life gives you lemons, write better error messages
#45Long 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: develope…
Very interesting idea! Adaptive UX seems under explored.
Re: When life gives you lemons, write better error messages
#46My most blood boiling error message (long time ago, maybe they fixed it): "No headset audio" -- displayed by the Oculus desktop app, in regards to not having audio on the headset. There's a "learn more" link, which would send you to the general troubleshooting FAQ. So, the program knows something is wrong with the audio, but completely refuses to say what. Is it a headset problem, a driver problem, a restart needed!?…
> My most blood boiling error message (long time ago, maybe they fixed it):
I still have a screenshot from a long time ago from a Microsoft product and the error message reads something like that:
"Possible causes: xxx, yyy, your computer may be off".
That one is so dumb I took a screenshot back in the days and still have it somewhere in my backups.
What they meant was "the computer you're trying to contact may be off", not "your computer may be off". I honestly think that one takes the icing on the cake.
But I've got another contender screenshot, still from a Microsoft product, saying something like this: "We suggest you write the following password down: z_7-9$HqR2_vM5$pL8-wN1_bX4$kZ7-jT0_yC3$fS6-uG9_aD2$hI5-rP8_eQ1$mW4E8_oQ1$tV4-6_x$K9_j-2$G5_s-8$W1_b-4$N7_m-0$Z" [1]
This was pre-ubiquitous QR code days.
[1] and, yes, it was so dumb I preferred to take a screenshot of the password than be "secure", so I could make fun of that message forever. And I gotta say, that screenshot did age like fine wine.
Re: When life gives you lemons, write better error messages
#47Readable link: https://archive.md/N1Eg9
Re: When life gives you lemons, write better error messages
#48Error: 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…
As someone who is a penetration tester, I can assure you that this is a TERRIBLE idea. Look up "CWE-200". While you are correct that this might help someone fix an issue, I can assure you it will help MANY more people to understand the technology stack you are working with and allow them to exploit unpatched vulnerabilities in your tech stack.
Re: When life gives you lemons, write better error messages
#49Error: 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…
As someone who is a penetration tester, I can assure you that this is a TERRIBLE idea. Look up "CWE-200". While you are correct that this might help someone fix an issue, I can assure you it will help MANY more people to understand the technology stack you are working with and allow them to exploit unpatched vulnerabilities in your tech stack.
And all these years I was told security through obscurity wasn't a thing...
I work on desktop applications. Tech stack is visible to anyone who can see the error message.
If you got a web-based SaaS sure I understand your position, but then you spit all that good stuff into a log and have the error message include the relevant log ids so support can easily find it. If something bad happens while loading a file, include the filename in the logs, and so on.
Re: When life gives you lemons, write better error messages
#50[dead]