6 ms·

When life gives you lemons, write better error messages

172 points by luispa 5mo ago

magicalhippo 5mo ago
Error: 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 harder time figuring out what the real issue might be, in order to work around it. Failed to load a shared library? State the filename and exact error code and message, and anything else that might be useful. And so on.
- mandevil 5mo ago
  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.
  - landr0id 5mo ago
    Static analysis tools + MCP server + a debugger with an MCP server makes reverse engineering incredibly easy and low-cost. I wrote a blog post about this recently: https://landaire.net/reverse-engineering-with-ai/ https://landaire.net/reverse-engineering-with-ai/ Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.
  - vector_spaces 5mo ago
    This is security through obscurity -- can complement other methods but won't do much for you against competent adversaries.
    - pixl97 5mo ago
      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.
  - EvanAnderson 5mo ago
    > 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. As a sysadmin (having spent 30 years dealing with desktop software) the attitude of the people who gave you that direction make me seethe with anger. Crackers gonna crack. That just hurts the people who have to make the product work in their environment.
- arjie 5mo ago
  I've done this to myself because I was too lazy to write the `fmt!()` instead of the raw string while I was iterating and then just forgot to fix it later. I think the Go logger's default of accepting chained parameters that it logs by default to JSONL worked well to avoid that. Convenient ergonomics just in time (in the cosmic sense of programming) for it all to be irrelevant because an LLM always puts it in the error string.
- deleted 5mo ago
  [deleted]
- dec0dedab0de 5mo ago
  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.
  - ozim 5mo ago
    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.
    - dmd 5mo ago
      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.
      - pixl97 5mo ago
        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.
      - bluGill 5mo ago
        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.
      - protocolture 5mo ago
- Insanity 5mo ago
  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.
  - t-writescode 5mo ago
    Maybe in the UX; but for the love of all things, please shove that data in a user-accessible error log, with enough verbosity that someone could debug it themselves. I am so tired of having to submit a HUGE FUCKING FILE that includes a ton of PII to customer support, only for them to ask the same “did you try uninstalling and reinstalling the app?” (Yes.) afterward.
  - deleted 5mo ago
    [deleted]
  - 8note 5mo ago
    expected what to be a number? what i have is a string. how do i turn my string into a relevant number?
  - setr 5mo ago
    The action on an unhandled / unexpected exception is “please submit this information to your closest administrator” And then dump whatever you want, with a copy button
    - doublerabbit 5mo ago
      Then you find the bug report form was deactivated and the message never being updated. So your now stuck with an error and no where to report it to.
      - rootnod3 5mo ago
        Still better than an error message with pretty much zero info.
- hekkle 5mo ago
  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.
  - magicalhippo 5mo ago
    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.
    - hekkle 5mo ago
      You're right, this is more for web applications than for desktop applications.
- nazgul17 5mo ago
  You can have both of you provide an error code that your support team can look up in the logs to find the complete error message.
- superjan 5mo ago
  I’ve learned this lesson over the years. It is quite common that users make a screenshot of the error with their phone, and send it on to support with hardly any details. The fact that errors become recognizably different is also an improvement: the user and support staffer can recognize recurring errors, and notice patterns.
- frevib 5mo ago
  To the user: friendly message with uuid. In the logs: detailed technical message with uuid.
harperlee 5mo ago
Hopefully 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, can be searched on the internet, can be passed around on a ticket or on a call... add parameters to your error template, reference the name of the file, the item name that does not respond, the HTTP error code... just give the user some transparency, some agency. Help the client build up a mental model of the error: when / how / why might it be happening.
- Groxx 5mo ago
  I'm somewhat fond of including a UUID for that reason. As long as they can copy-paste it into Google, they can get results that are precisely the errors from your application, unlike "error 55324". The same works internally: zero ambiguity which system it came from, and it's trivial to find the full history of the error (message). It's not great for verbally communicating tho. But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.
  - pseudohadamard 5mo ago
    IBM have been doing this for centuries, each error comes with a code you can look up for more information. Although this is probably way too late, all nix/nux utilities should come with either a magic ID string you can copy into Google to find all the other people baffled by the same error message ("Quadrant change in relocatable expression", that's an actual error message), or just an option to launch a browser with said info, because the message itself ain't giving you anything to go on.
- jagged-chisel 5mo ago
  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.
vector_spaces 5mo ago
You can certainly learn a bit about how a company thinks about UX, accessibility, and its users more broadly by looking at its error messages. Although I didn't care for much of the specifics proposed, I am glad about this post as I think it is important to think through error messages with intention and treat them as products in their own right. Regarding the proposed "good" alternative, it has less actionable information than the original "bad" message, depending on what the product is and who its users are. In particular, you can't determine whether "fetch data" is impenetrable jargon without looking at the product itself and its users. I also frequently see people use the designation of a user as non-technical as an excuse to dismiss their intelligence. It's true that tech folks generally underestimate how confusing computers and software are to the average person, but erring too heavily in the other direction also has negative impacts for accessibility. Either way, you can at least hide away that extra detail, with jargon and all, using that link tip she mentioned. Finally, this writer seems to overestimate the extent to which most users view "contact Customer Care" as "giving them a way out" and not an invitation for further aggravation.
HelloUsername 5mo ago
(I can't read the first part of the title without hearing Cave Johnson)
- rf15 5mo ago
  You're right, all error messages should be voiced by Cave Johnson.
CM30 5mo ago
I think this post has some interesting points, but it kinda misses a few more as well. First, appropriate tone depends heavily on the product or service in question. A bank or otherwise serious business should probably not be giving messages like "whoops, something went wrong". But an entertainment product could have those sorts of messages, and treat it as part of the overall experience. Secondly, I'm not a huge fan of error messages that don't give actionable feedback for how to fix the issue. Yes, a lot of users don't need that sort of information, but some sort of error code or technical reference can be handy for more involved support processes. So, if the product or service is business orientated, maybe have that info in a dropdown box or something, where a support agent can ask the user to find it if an issue keeps occurring. And of course, if the product or service is aimed at technical people (like an open source infrastructure project), maybe just skip the casual language and just get to the point.
randycupertino 5mo ago
"Oh no, you broke reddit." I didn't break it!!! Reddit is down and your server is overloaded.
- zahlman 5mo ago
  I'm pretty sure that one is intended to be a light-hearted joke.
croisillon 5mo ago
(2022)
utkarsh4995 5mo ago
[flagged]
wpollock 5mo ago
Long 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).
- wonger_ 5mo ago
  Very interesting idea! Adaptive UX seems under explored.
ragall 5mo ago
I 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.
- scottlamb 5mo ago
  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.
  - hungryhobbit 5mo ago
    I was so excited when I started the article: this person has thought hard about what makes a good error message and a bad error message. I was so excited to learn! But it turns out they were completely full of it, and have absolutely no idea what separates a good/bad message. Quite disappointing.
dale_glass 5mo ago
My 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!? Then to make it more fun, when I complained about this stuff originally I got the advice to upload a debug log. Ok, good. That failed every time with "The upload took too long, connection was lost". I pulled out the dev tools and then I saw that what the API actually returns is: [{"error":"Attachment is too large. Limit 20 megabytes."}] Bloody infuriating. They built a system that translates sensible errors into completely useless ones.
- bombcar 5mo ago
  Atlassian of all people did this right - you can upload a support zip and it warns if it’s large (do you want to try?) and gives you the option of (basically) the last 10/20 MB of logs to send instead.
- TacticalCoder 5mo ago
  > 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.
heocoi 5mo ago
Hit a fresh case of this last week porting an Astro layout. Wrote a literal `{` inside a `<pre>` code block. Build crashed with "Expected `}` but found `:`" pointing to a line:col that didn't exist in the source file. Took 20 minutes to realize the position was from the compiled JS output, not my .astro file. Fix was escaping to {. The error wasn't wrong, just orphaned from the user's mental model of where the bug lives.
skiing_crawling 5mo ago
My favorite useless error message is in chrome/brave: `DNS_PROBE_POSSIBLE`. If its possible, just do it?
4lx87 5mo ago
I'd also display an error ID to the user, which is tagged on the error log. That way engineers can instantly locate a detailed error log from a screenshot provided by the user.
timebeforeland 5mo ago
If I had a LLM generate fake HN headlines, this would be one of them. Let's do better guys.
- cindyllm 5mo ago
  [dead]
encom 5mo ago
Readable link: https://archive.md/N1Eg9 https://archive.md/N1Eg9
zty5678 5mo ago
[dead]
disfictional 5mo ago
I misread the title as "write bitter error messages", and that resonated with me deeply.
5uf 5mo ago
(2022) Prev discussions, Oct 2022, 250+ comments: https://news.ycombinator.com/item?id=33261125 https://news.ycombinator.com/item?id=33261125
tommica 5mo ago
Very good article, I've never given a big thought to my error messages, but clearly I should have. Going to snatch these rules and ideas!
Olivia_Rio 5mo ago
I still run into error messages like "Error", "Permission denied", or "Bad directory" that leave users guessing. Google's guide on writing error messages is pretty good: https://developers.google.com/tech-writing/error-messages https://developers.google.com/tech-writing/error-messages. The basic formula is simple: explain the problem, then explain the solution.
luodaint 5mo ago
My mindframe about error messaging: Errors are just a form of routing decision. The quality of the error message lies in the destination, not the message itself.
wolvoleo 5mo ago
Yeah I really hate Microsoft's terrible error messages lately. "Something went wrong". Like on teams. Well yeah no shit. But tell me something that actually helps.
rkozik1989 5mo ago
The reason people write vague error messages is because they deliberately do not want to give the user information on implementation details because that information can be use in hacks and/or social-engineering.
diamondosas 5mo ago
i dont understand hackernews
iqfareez 5mo ago
[dead]
seoulful 5mo ago
[dead]

172 points by luispa 5mo ago

Error: 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 harder time figuring out what the real issue might be, in order to work around it. Failed to load a shared library? State the filename and exact error code and message, and anything else that might be useful. And so on.

mandevil 5mo ago
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.
- landr0id 5mo ago
  Static analysis tools + MCP server + a debugger with an MCP server makes reverse engineering incredibly easy and low-cost. I wrote a blog post about this recently: https://landaire.net/reverse-engineering-with-ai/ https://landaire.net/reverse-engineering-with-ai/ Just yesterday I completely reverse engineered several proprietary audio codecs from a game without even having to touch the static analysis tool myself.
- vector_spaces 5mo ago
  This is security through obscurity -- can complement other methods but won't do much for you against competent adversaries.
  - pixl97 5mo ago
    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.
- EvanAnderson 5mo ago
  > 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. As a sysadmin (having spent 30 years dealing with desktop software) the attitude of the people who gave you that direction make me seethe with anger. Crackers gonna crack. That just hurts the people who have to make the product work in their environment.
arjie 5mo ago
I've done this to myself because I was too lazy to write the `fmt!()` instead of the raw string while I was iterating and then just forgot to fix it later. I think the Go logger's default of accepting chained parameters that it logs by default to JSONL worked well to avoid that. Convenient ergonomics just in time (in the cosmic sense of programming) for it all to be irrelevant because an LLM always puts it in the error string.
deleted 5mo ago
[deleted]
dec0dedab0de 5mo ago
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.
- ozim 5mo ago
  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.
  - dmd 5mo ago
    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.
    - pixl97 5mo ago
      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.
    - bluGill 5mo ago
      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.
    - protocolture 5mo ago
Insanity 5mo ago
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.
- t-writescode 5mo ago
  Maybe in the UX; but for the love of all things, please shove that data in a user-accessible error log, with enough verbosity that someone could debug it themselves. I am so tired of having to submit a HUGE FUCKING FILE that includes a ton of PII to customer support, only for them to ask the same “did you try uninstalling and reinstalling the app?” (Yes.) afterward.
- deleted 5mo ago
  [deleted]
- 8note 5mo ago
  expected what to be a number? what i have is a string. how do i turn my string into a relevant number?
- setr 5mo ago
  The action on an unhandled / unexpected exception is “please submit this information to your closest administrator” And then dump whatever you want, with a copy button
  - doublerabbit 5mo ago
    Then you find the bug report form was deactivated and the message never being updated. So your now stuck with an error and no where to report it to.
    - rootnod3 5mo ago
      Still better than an error message with pretty much zero info.
hekkle 5mo ago
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.
- magicalhippo 5mo ago
  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.
  - hekkle 5mo ago
    You're right, this is more for web applications than for desktop applications.
nazgul17 5mo ago
You can have both of you provide an error code that your support team can look up in the logs to find the complete error message.
superjan 5mo ago
I’ve learned this lesson over the years. It is quite common that users make a screenshot of the error with their phone, and send it on to support with hardly any details. The fact that errors become recognizably different is also an improvement: the user and support staffer can recognize recurring errors, and notice patterns.
frevib 5mo ago
To the user: friendly message with uuid. In the logs: detailed technical message with uuid.

harperlee 5mo ago

Hopefully 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, can be searched on the internet, can be passed around on a ticket or on a call... add parameters to your error template, reference the name of the file, the item name that does not respond, the HTTP error code... just give the user some transparency, some agency. Help the client build up a mental model of the error: when / how / why might it be happening.

Groxx 5mo ago
I'm somewhat fond of including a UUID for that reason. As long as they can copy-paste it into Google, they can get results that are precisely the errors from your application, unlike "error 55324". The same works internally: zero ambiguity which system it came from, and it's trivial to find the full history of the error (message). It's not great for verbally communicating tho. But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.
- pseudohadamard 5mo ago
  IBM have been doing this for centuries, each error comes with a code you can look up for more information. Although this is probably way too late, all nix/nux utilities should come with either a magic ID string you can copy into Google to find all the other people baffled by the same error message ("Quadrant change in relocatable expression", that's an actual error message), or just an option to launch a browser with said info, because the message itself ain't giving you anything to go on.
jagged-chisel 5mo ago
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.

vector_spaces 5mo ago

You can certainly learn a bit about how a company thinks about UX, accessibility, and its users more broadly by looking at its error messages. Although I didn't care for much of the specifics proposed, I am glad about this post as I think it is important to think through error messages with intention and treat them as products in their own right. Regarding the proposed "good" alternative, it has less actionable information than the original "bad" message, depending on what the product is and who its users are. In particular, you can't determine whether "fetch data" is impenetrable jargon without looking at the product itself and its users. I also frequently see people use the designation of a user as non-technical as an excuse to dismiss their intelligence. It's true that tech folks generally underestimate how confusing computers and software are to the average person, but erring too heavily in the other direction also has negative impacts for accessibility. Either way, you can at least hide away that extra detail, with jargon and all, using that link tip she mentioned. Finally, this writer seems to overestimate the extent to which most users view "contact Customer Care" as "giving them a way out" and not an invitation for further aggravation.

HelloUsername 5mo ago

(I can't read the first part of the title without hearing Cave Johnson)

rf15 5mo ago
You're right, all error messages should be voiced by Cave Johnson.

CM30 5mo ago

I think this post has some interesting points, but it kinda misses a few more as well. First, appropriate tone depends heavily on the product or service in question. A bank or otherwise serious business should probably not be giving messages like "whoops, something went wrong". But an entertainment product could have those sorts of messages, and treat it as part of the overall experience. Secondly, I'm not a huge fan of error messages that don't give actionable feedback for how to fix the issue. Yes, a lot of users don't need that sort of information, but some sort of error code or technical reference can be handy for more involved support processes. So, if the product or service is business orientated, maybe have that info in a dropdown box or something, where a support agent can ask the user to find it if an issue keeps occurring. And of course, if the product or service is aimed at technical people (like an open source infrastructure project), maybe just skip the casual language and just get to the point.

randycupertino 5mo ago

"Oh no, you broke reddit." I didn't break it!!! Reddit is down and your server is overloaded.

zahlman 5mo ago
I'm pretty sure that one is intended to be a light-hearted joke.

croisillon 5mo ago

(2022)

utkarsh4995 5mo ago

[flagged]

wpollock 5mo ago

Long 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).

wonger_ 5mo ago
Very interesting idea! Adaptive UX seems under explored.

ragall 5mo ago

I 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.

scottlamb 5mo ago
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.
- hungryhobbit 5mo ago
  I was so excited when I started the article: this person has thought hard about what makes a good error message and a bad error message. I was so excited to learn! But it turns out they were completely full of it, and have absolutely no idea what separates a good/bad message. Quite disappointing.

dale_glass 5mo ago

My 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!? Then to make it more fun, when I complained about this stuff originally I got the advice to upload a debug log. Ok, good. That failed every time with "The upload took too long, connection was lost". I pulled out the dev tools and then I saw that what the API actually returns is: [{"error":"Attachment is too large. Limit 20 megabytes."}] Bloody infuriating. They built a system that translates sensible errors into completely useless ones.

bombcar 5mo ago
Atlassian of all people did this right - you can upload a support zip and it warns if it’s large (do you want to try?) and gives you the option of (basically) the last 10/20 MB of logs to send instead.
TacticalCoder 5mo ago
> 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.

heocoi 5mo ago

Hit a fresh case of this last week porting an Astro layout. Wrote a literal `{` inside a `<pre>` code block. Build crashed with "Expected `}` but found `:`" pointing to a line:col that didn't exist in the source file. Took 20 minutes to realize the position was from the compiled JS output, not my .astro file. Fix was escaping to {. The error wasn't wrong, just orphaned from the user's mental model of where the bug lives.

skiing_crawling 5mo ago

My favorite useless error message is in chrome/brave: `DNS_PROBE_POSSIBLE`. If its possible, just do it?

4lx87 5mo ago

I'd also display an error ID to the user, which is tagged on the error log. That way engineers can instantly locate a detailed error log from a screenshot provided by the user.

timebeforeland 5mo ago

If I had a LLM generate fake HN headlines, this would be one of them. Let's do better guys.

cindyllm 5mo ago
[dead]

encom 5mo ago

Readable link: https://archive.md/N1Eg9 https://archive.md/N1Eg9

zty5678 5mo ago

[dead]

disfictional 5mo ago

I misread the title as "write bitter error messages", and that resonated with me deeply.

5uf 5mo ago

(2022) Prev discussions, Oct 2022, 250+ comments: https://news.ycombinator.com/item?id=33261125 https://news.ycombinator.com/item?id=33261125

tommica 5mo ago

Very good article, I've never given a big thought to my error messages, but clearly I should have. Going to snatch these rules and ideas!

Olivia_Rio 5mo ago

I still run into error messages like "Error", "Permission denied", or "Bad directory" that leave users guessing. Google's guide on writing error messages is pretty good: https://developers.google.com/tech-writing/error-messages https://developers.google.com/tech-writing/error-messages. The basic formula is simple: explain the problem, then explain the solution.

luodaint 5mo ago

My mindframe about error messaging: Errors are just a form of routing decision. The quality of the error message lies in the destination, not the message itself.

wolvoleo 5mo ago

Yeah I really hate Microsoft's terrible error messages lately. "Something went wrong". Like on teams. Well yeah no shit. But tell me something that actually helps.

rkozik1989 5mo ago

The reason people write vague error messages is because they deliberately do not want to give the user information on implementation details because that information can be use in hacks and/or social-engineering.

diamondosas 5mo ago

i dont understand hackernews

iqfareez 5mo ago

[dead]

seoulful 5mo ago

[dead]