Live data from Hacker News

Write better error messages

wix-ux.com

51–60 of 265 posts

Re: Write better error messages

#51

Probably just me, but I am less concerned with how good my error messages are, and more concerned with trying very very hard to make the errors happen closer to the cause of the problem, rather than further away. "Fail early, fail hard" i.e. if I can make the error message happen near the beginning of a process, I can get away with making it a hard error. Hard errors in the middle of a multi-hour operation tend to an…

That's not really a respectful practice. Error messages should be clear and actionable.

Users don't care if you consider an error soft or hard.

Re: Write better error messages

#52
post #44

If you're raising an exception deep in some internal code, provide as much detail as possible. If the error bubbles up to the user, then either the information is over their head, in which case there's no difference to a non-detailed error message, or the user/support person can actually act on it. The most infuriating error I see is "file not found"... WHICH FILE?! Of course if the error is found in the higher level…

> The most infuriating error I see is "file not found"... WHICH FILE?! Filenames might contain user data, which must not be logged outside of a database with proper access control, schema annotations, and acccess auditing. We can only display an opaque object key, so authorized devs can look up the filename using secure tools.

Fair enough. I work mostly with good old desktop applications though, so if there's user data, it's almost always the users data.

For the majority of errors in most applications one can provide some helpful information. But yeah, one need to be a bit careful if one has PII in the mix.

Re: Write better error messages

#54
My recent experience with docker, I am a total newb so I was running a tutorial step by step, then I get some error about apt certificates/keys/repo stuff. After lot of googling the issue was there was not enough disk space but the fucking error was pointing in a different direction. Also this is a good example why Stack Overflow is usefull for the dudes that hate on it and RTFM everyone else.

This is why I love exceptions, I had an issue with a C# game, but with a stack trace I could figure out myself that the issue is happening when the app initialize and fails to open a file.

I think twe should always give the users a detailed log and stack traces, also docker should fucking have some way to catch the issue when there is not enough space and report the error properly.

Re: Write better error messages

#55
post #39

Earlier quoted context omitted.

Don't send people somewhere else to learn how to fix the error. The more steps and indirection you add the fewer people will bother doing it themselves, especially if they can bump it to the developer. Make it easy for people to fix their own problems by being explicit, direct and complete. List all the steps and use formatting to make it visually easier to consume. So your error message while a far cry from the wors…

I think his point was the developer tends not to even investigate the ENVVAR at issue or visit the link. If the developer does investigate the link and still has an issue, than you have a point.

Pretty sure his problem was he got contacted about an issue he considers uninteresting, and his preferred solution is the user stops behaving like a human.

Reaching for the easiest way to solve a problem first is a very human thing to do, and in this case he was easier to contact than opening up a browser and reading an article that presumably is written in the same kind of language as the error message.

Re: Write better error messages

#57
post #49

Earlier quoted context omitted.

This just means that the error message needs to be more clear. For example, after the error itself, it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to . Set ENVVAR to a proper value and restart the service.” Notice the direct language. It reads like an order. The less direct the message, the higher the chances that the user will not act upon it.

The problem is people are not rational… and we try to solve that with software. Many people just lock up when software doesn’t do what they expect.

Not rational people must be fired from IT.

Re: Write better error messages

#59
post #49

Earlier quoted context omitted.

The problem is people are not rational… and we try to solve that with software. Many people just lock up when software doesn’t do what they expect.

Not rational people must be fired from IT.

Generally a pipe dream in my experience.

Re: Write better error messages

#60
post #16

> Even in today’s world of user-centered design, technical jargon still sneaks its way into error messages. You couldn’t fetch my data? My credentials were denied? What? The technical stuff is not important to the user This is the opposite of what I want. Stop condescending and just tell me what actually went wrong.

I have this issue with Google Family Link, where I want to add my child's voice to a Nest Audio. The app straight up tells me that I'm not connected to the wifi, which is clearly not true. Furthermore, the app knows I'm connected because in the logging you can see it finding the Nest Audio.

It's impossible to figure out what goes wrong. Plenty of people have the same problem, but Google only has this forum where superusers assume everybody else is either lying or an idiot. Meanwhile, they take such error messages at face value, despite many people saying they have wifi.

All that to say that I'd rather have an overly technical error that actually tells me what's wrong, instead of a friendly error message that's straight up wrong.

Post reply on HN