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

71–80 of 265 posts

Re: Write better error messages

#71

Post by starkd »

chillfox wrote: post #55
starkd wrote: post #39

Earlier quoted context omitted.

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.

I admit to doing this. Even many of the useful error messages that clearly indicate the fix are drowned out out by the mass of output. I've made this mistake before, and I'll probably do so again.

Re: Write better error messages

#72

Post by chillfox »

dvtrn wrote: post #68
chillfox wrote: post #55

Earlier quoted context omitted.

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.

I’m left wonder at what point does the “give a man a fish/teach a man how to fish” method of pedagogy apply in terms of ‘acting like a human’ in this context? Asking as someone who otherwise generally agrees that there are some truly poorly written errors and exceptions out there, but has also been on the admittedly frustrating end of the constant requests for help deciphering error messages that were very plainly st…

Sure, clearly there are people who will never try, or learn, but in general as an industry I feel like the wast majority of errors are very very far from good.

Few error messages are written well, has good formatting and are self contained (can be used to fix the issue without having to seek further information elsewhere). Sometimes you see errors that contain one of those elements, but rarely all of them.

There has been an effort the last few years improving compiler errors for some languages, but those same improvements have not reached applications.

Re: Write better error messages

#73

Post by Spivak »

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 ?

Errors on initialization, fatal errors, and non-recurrent errors that require human/support intervention should be documentation.

Re: Write better error messages

#74

Post by chillfox »

starkd wrote: post #71
chillfox wrote: post #55

Earlier quoted context omitted.

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.

I admit to doing this. Even many of the useful error messages that clearly indicate the fix are drowned out out by the mass of output. I've made this mistake before, and I'll probably do so again.

I feel like this is a problem of overly chatty application logs + lack of formatting for errors.

If the volume of drivel was lowered and errors were formatted with spacing and color to stand out, then they would be easier to focus on.

So log errors to stderr, send it to a separate log file, and format it well (use multiple lines).

Re: Write better error messages

#75

Post by deathanatos »

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.

This; particularly because more and more, "support" seemingly has no means to access logs, no ability to do the debugging, and no way to escalate obvious bugs in the application to the developers.

I need the technical jargon to do support's — and the company whose product I'm using's — job for them.

Is it not helpful to laypeople? Perhaps not, but it is what the technical friend they're going to drag into the problem needs.

Re: Write better error messages

#76

Post by Aperocky »

MiddleMan5 wrote: post #47
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.

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

Don't blame developer culture, if that error cannot be acted on, attribute to incompetence and not culture.

Re: Write better error messages

#77

Post by lijogdfljk »

nerdponx wrote: post #38
jimmytidey wrote: post #26

Earlier quoted context omitted.

This is a context where people are used to seeing errors that they don't know what to do with. If a web app pops a well written error it is much more likely to be acted on than an unmotivated dev seeing a some (probably badly formatted) text. Every time I see an error in terminal with a link to documentation I'm delighted. And surprised.

So? That's no excuse for a developer to disregard the content of an error message in their own application.

It kinda is. Kinda like when documentation is so repeatedly outdated and incorrect, that when you need new information you just skip documentation entirely.

Are you wrong for skipping documentation? Yea, maybe. Is it entirely expected? Yea.

Based on the parent comment, at least.

Re: Write better error messages

#78

Post by rjmill »

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:…

> evidence at all that they would be read

I just had an idea: Put tracking info in the error URL. If your company has an internal URL shortener, that could do the trick.

More practically, I feel like it helps to put an empty line before the call to action. For many people, a traceback is just noise. The empty line helps split the useful info out from the traceback.

Or if it's a script/CLI (and you know the error reason) don't even show a traceback. Just print the error message to stderr, exit non-zero, and be done with it.

Re: Write better error messages

#79

Post by marginalia_nu »

FartyMcFarter wrote: post #28

I've been guilty of this in the past - I remember writing an error message that looked like "if you used X setting, do this, otherwise that". The code should have instead checked what settings the user enabled and given a clearer error for the situation at hand.

That sort of code is a bit tricky though.

Since the fault code paths (hopefully) are very rarely executed, the error messages are easy to overlook, and tend to rapidly become stale. This is to an extent always a problem with error messages, but it's an ever bigger problem when you have half a dozen error messages depending on various parameters, since they create more and even more rare code paths for staleness to hide in.

Re: Write better error messages

#80

Post by JTbane »

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:…

>>>“RuntimeError: Did not find ENVVAR, ensure this is set to the proper value (see ) and then restart this service”

I'm laughing as you could not make it clearer if you tried. PEBKAC

Post reply on HN