Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write better error messages

wix-ux.com

Post reply on HN
Print view View original

41–50 of 265 posts

Re: Write better error messages

#41

Post by chillfox »

mariusmg wrote: post #17
zagrebian wrote: post #8

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.

>it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to . Set ENVVAR to a proper value and restart the service.” Really, should logs also be documentation now ? Just mindlessly logging the same "advice" over and over again each time the error happen ?

Yes! We have tools to filter what gets saved and compression that handles repeated text very well.

So why not provide docs on how to solve the error along with the error.

Re: Write better error messages

#43

Post by lupire »

upofadown wrote: post #4

There are fundamentally two classes of error message: 1. Information that can help a technically engaged person debug a problem. 2. Information that can help a user of the system understand what they have to do the overcome the problem. Since most error messages are created by people responsible for debugging the system they tend to be of the 1st class. There has to be a way to provide different information based on…

It's easy. Just provide both, with mark-up to label them.

Re: Write better error messages

#44

Post by lupire »

magicalhippo wrote: post #13

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.

Re: Write better error messages

#45

Post by dvtrn »

ckozlowski wrote: post #31
j-bos wrote: post #21

Earlier quoted context omitted.

I think the original error is quite clear, under normal circumstances. Not OP but I've noticed that people often get brain fog when something goes wrong and are often need BIG, SHORT, WORDS to shake out of it. Or really anything that can shake them out of the 'idunno' state of mind. But maybe if something like that became standard ut would no longet be a context switcher..

I think you're spot on, and I made a similar comment above. It's easy to say "they can figure it out". Sure, in a restful state. But the people we're asking to take action already have a lot on their plate. Using plain, conversational language whenever possible with exceedingly clear steps means less mental exertion on the receiver. And since we need their help, anything we can do to make it easier on their end helps…

These are fascinating responses to me, as with the example given my mind first went to someone for whom English is a second language. that group having trouble with this message I would understand, or at least have an easier time understanding having trouble, if even a very little amount.

For someone who was born speaking English and spoke it their entire lives, the example provided couldn’t possibly be more to the point in my opinion.

Though I agree overall with the general idea and that yes there are some pretty baffling and downright awfully written error messages and log entries that take a minute to grok (I just don’t think the example replied to is one of them).

Re: Write better error messages

#46

Post by lupire »

grandinj wrote: post #22
hprotagonist wrote: post #3

I would, if i had any evidence at all that they would be read and acted on. I’m convinced even seemingly competent people are just rendered contextually blind by the appearance of any error at all. In the past month, i’ve had about a dozen interactions like this: developer: your service crashed, here’s a screenshot of the last 5 lines of the crash me: do you see where the final text you just pasted is “RuntimeError:…

Some developers are just lazy, and will likely need some kind of negative feedback to force them to confront their own laziness. Which can be tricky, because the degree of negative feedback that is appropriate to the person in question can range from "Polite one-on-one suggestion that you read the error message more than once before calling me" to "Full on yelling at the person in the middle of an open-plan office".…

Send a link to wiki. Last line of page is "if you have questions, reach out and include the keyword $THIS_PAGE_KEY in your message."

Re: Write better error messages

#47

Post by MiddleMan5 »

zagrebian wrote: post #8
hprotagonist wrote: post #3

I would, if i had any evidence at all that they would be read and acted on. I’m convinced even seemingly competent people are just rendered contextually blind by the appearance of any error at all. In the past month, i’ve had about a dozen interactions like this: developer: your service crashed, here’s a screenshot of the last 5 lines of the crash me: do you see where the final text you just pasted is “RuntimeError:…

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.

I can't tell if this is sarcasm or not, this is obviously highlighting a deeper issue in developer culture.

The example given was clear compared to 90% of other error messages, and saying that it needs to be "more clear" is almost dismissive

Re: Write better error messages

#48

Post by aeonik »

jaywalk wrote: post #30
donatj wrote: 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.

It all depends on the context. If it's a web application that can't connect to some backend service, for example, what exactly are you going to do with that information?

Depends on why it didn't connect, right?

Was it a timeout? Maybe an HTTP 401 Was it a DNS failure Was there a TCP reset immediately?

Each one has a miriad of troubleshooting steps associated with it. Some could be local to the host, some could be network/firewall some could be from the remote host or behind that.

Re: Write better error messages

#49

Post by duxup »

zagrebian wrote: post #8
hprotagonist wrote: post #3

I would, if i had any evidence at all that they would be read and acted on. I’m convinced even seemingly competent people are just rendered contextually blind by the appearance of any error at all. In the past month, i’ve had about a dozen interactions like this: developer: your service crashed, here’s a screenshot of the last 5 lines of the crash me: do you see where the final text you just pasted is “RuntimeError:…

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.

Re: Write better error messages

#50

Post by throw827474737 »

ddulaney wrote: post #32
mariusmg wrote: post #17

Earlier quoted context omitted.

>it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to . Set ENVVAR to a proper value and restart the service.” Really, should logs also be documentation now ? Just mindlessly logging the same "advice" over and over again each time the error happen ?

Logs can definitely be a form of documentation. I write software that is generally run low in the stack, quietly doing some mundane tasks that are business-critical but rarely thought about. If one of our clients has to mess with our software beyond the occasional update, that was a failing. Not all software is like this, but lots of it is -- its value is that no human needs to be involved. I need to write log messag…

If it is that simple, the why doesn't the code fix it itself? But no, usually there is 1/2/3 likely things, but it also could be anything else.. and that kind if unexpected errors even often have no default-fix.

No, the most best thing is to point to the documentation which has that, and not printig out manpages of docs in error messages now.

> I write software that is generally run low in the stack

What stack, how low? Me too.. that low that I usually cannot return or even log a " see error code doc at http.." string for various reasons (bandwidth, mem, performance) but only have error codes ;)

Post reply on HN