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

161–170 of 265 posts

Re: Write better error messages

#161

Post by tlogan »

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 is 100% correct.

In theory, all errors should: explain the input, explain the problem and explain how to solve the problem (actions). And that should help and reduce number of support calls. However, error messages and actions how to solve the error are read by maybe 1% of users.

The only way to improve your UI is to prevent errors and use standards / familiar design.

Re: Write better error messages

#162

Post by [deleted] »

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

[deleted]

Re: Write better error messages

#163

Post by [deleted] »

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.

[deleted]

Re: Write better error messages

#164

Post by PetahNZ »

Minor49er wrote: post #114

At a previous job, writing unambiguous error messages was discouraged. Everything just had to be "Oops! Something went wrong" The reasoning was that "users can't do anything with information we tell them anyways", despite the overwhelming number of help desk tickets we'd get from "Oops!" appearing in a million different scenarios with no clear way for us to tell what error actually caused the message to appear. Users…

As long as you are logging the error with the context somewhere that's fine. You could always include a timestamp or request ID with the user message to not give away information, but be able to easily search your logs for the occurrence.

Re: Write better error messages

#165

Post by e40 »

Tried to download my data from takeout.google.com and got this error:

"500. It's an error."

Thanks, google. I tried to start a chat (I'm a Workspace customer) and could not continue because all the language choices were disabled (even English).

Re: Write better error messages

#166

Post by S201 »

Merad wrote: post #155
grandinj wrote: post #27

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…

This is an attitude I really try to build up in junior devs. Soooo many people seem to default to writing code like, "if input is null return null" (when input should never be null) or "if valueThatShodBePositive I guess this is because no one really teaches error handling. I assume a lot of students end up with a mindset of just make the errors go away instead of, deal with the errors effectively.

Agreed; I've often wondered if this is a result of early CS classes usually expecting students to handle weird/bad inputs. It's only natural for a programmer to want to write a program that gracefully handles all reasonably bad inputs, like nulls. So we're taught early on to write defensive code that handles those. And that's fine when you're writing short, academic programs. But when the complexity goes up by a few orders of magnitude trying to gracefully handle that null value 10 levels deep in some parsing logic maybe isn't the best thing to do. Old habits die hard, however.

Re: Write better error messages

#167

Post by rockemsockem »

MattGaiser wrote: post #137
Minor49er wrote: post #114

At a previous job, writing unambiguous error messages was discouraged. Everything just had to be "Oops! Something went wrong" The reasoning was that "users can't do anything with information we tell them anyways", despite the overwhelming number of help desk tickets we'd get from "Oops!" appearing in a million different scenarios with no clear way for us to tell what error actually caused the message to appear. Users…

I have only worked at one place that wanted informative error messages. All the others wanted to hide the reason because "if we know the reason and tell the user, we seem incompetent" or "then hackers will know which API call isn't working right" (apparently the network console in Chrome is beyond hackers) to wanting customers to be dependent as they paid for support.

People who don't know anything about computer security use it as a bludgeon to not do the thing that they didn't want to do anyway.

Re: Write better error messages

#168

Post by jeremy_wiebe »

I'm not sure we'll ever eclipse the awesomeness of the VB6 error: "Method ~ of object ~ failed".

On a more serious note, error messages is something I always try to keep in mind on in code reviews. Most error messages the code I review deals with are only ever seen in production logs, so I try to think what I'd do with that message (and accompanying details) if I saw it in production.

Re: Write better error messages

#169

Post by cpeterso »

If you have tech support or knowledge base articles for your product, you can include unique error codes in your error messages so that Googling the error code will find the appropriate support article. Microsoft is pretty good about this with their KB article numbers and their compiler error messages like C4000: https://learn.microsoft.com/en-us/cpp/error-messages/compile...

Re: Write better error messages

#170

Post by nightpool »

S201 wrote: post #166
Merad wrote: post #155

Earlier quoted context omitted.

This is an attitude I really try to build up in junior devs. Soooo many people seem to default to writing code like, "if input is null return null" (when input should never be null) or "if valueThatShodBePositive I guess this is because no one really teaches error handling. I assume a lot of students end up with a mindset of just make the errors go away instead of, deal with the errors effectively.

Agreed; I've often wondered if this is a result of early CS classes usually expecting students to handle weird/bad inputs. It's only natural for a programmer to want to write a program that gracefully handles all reasonably bad inputs, like nulls. So we're taught early on to write defensive code that handles those. And that's fine when you're writing short, academic programs. But when the complexity goes up by a few…

Yeah, this is a great point. Both overly defensive programming and (my personal least favorite) overly-commented code are instilled in students at a very early point in their careers by irresponsible teachers trying to find something to grade students on (Didn't handle negative values? 5 points off! Didn't leave a comment on every line? 1 point off per line!)
Post reply on HN