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

11–20 of 265 posts

Re: Write better error messages

#11

Post by koblas »

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…

The error message that is presented to the user should always be clear and helpful. When an error is presented to the user, you should have matching logging (e.g. sentry) that provides technical reporting on what happened. By having both solutions in place you have error handling that is complete and services both communities.

Re: Write better error messages

#12

Post by FridayoLeary »

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…

There's also a third class which is “Oops! Something went wrong…” which basically means "i don't know. Try and reload the page." Why this is better then a simple "error" is beyond me, but its mildly fustrating.

Re: Write better error messages

#13

Post by magicalhippo »

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 due to some consistency check in the business logic, then yeah try to guide the user. But for internal stuff, try to help the person who needs to fix it or find a workaround. It might be you.

Re: Write better error messages

#14

Post by dvtrn »

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’m not seeing how what the message already is any less direct or clear than what you’re saying it should be? It straight up tells you it can’t find the var and what to do about it.

Can you help me understand what isn’t clear about the message as is, or maybe point out the ambiguity to someone who just isn’t seeing it? I want to write better error messages but I share the frustration of the above poster. The message tells you specifically what to do, but you’re coming back saying it’s not clear.

Re: Write better error messages

#15

Post by mttjj »

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…

> There has to be a way to provide different information based on who is getting the error.

Yes, this concept exists. The error message that is shown to the user (number 2) is what's discussed in the article. The error message that an engineer or someone else debugging the system should get (number 1) is the full stack trace and data dump that should be sent to the application log at the same time that the user is shown the error dialog.

Users can fix the problem by following the instructions in the error dialog and engineers or technical people can come back later and look at the more detailed stack trace to determine the best course of action.

Re: Write better error messages

#16

Post by donatj »

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

Re: Write better error messages

#17

Post by mariusmg »

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.

>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 ?

Re: Write better error messages

#18

Post by pydry »

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.

It more likely means that the developer views the service as OP's responsibility. They'll view an order as something OP needs to do.

The clarity of the error message doesnt really matter if the recipient believes it is intended for somebody else.

Re: Write better error messages

#19

Post by londons_explore »

A big part of this is to direct more of your development time into errors that happen more frequently.

Most systems I was involved in designing have some kind of error tracking system, so we can know exactly how often each error occurs.

An error that never happened needs (usually) no attention.

An error that 28% of installations have seen needs a lot of attention. The error text should be translated into local languages, wiki pages should be written about how to resolve it, efforts should be made to auto-resolve the error. The error message should include helpful info, etc.

Eg. "SSH server can't start. Config file unreadable".

Could be split into:

SSH server can't start. Config file error on line 7. 'AllowPasswordLoogin' is an invalid setting. Did you mean 'AllowPasswordLogin'? If you want to make this change, 'sudo nano /etc/sshserver.conf' will let you change this config.

Re: Write better error messages

#20

Post by MetaWhirledPeas »

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…

> There has to be a way to provide different information based on who is getting the error.

This is already solved. Provide one error to the user and another to your logging system. In the user error provide a mechanism to point you to the logged error (even a simple timestamp helps).

Post reply on HN