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

141–150 of 265 posts

Re: Write better error messages

#141

Post by vladvasiliu »

Too wrote: post #138
marklubi wrote: post #87

Earlier quoted context omitted.

The trick that I've found is that each error message needs to be unique... not just the stack trace, but the actual wording of the message leading up to that. Get a screenshot or the exact verbatim of it, and you can identify exactly where in the code it originated. User reports are unreliable, but when I can pinpoint where the message originated from, it massively cuts down on the troubleshooting time.

About that, the number of developers that can’t read, or even understand the value of, a stack trace is also astonishing. If only I had a penny every time someone sent me a “log of the error”, that only contains the final line with the unhelpful message saying nothing but KeyError.

Forget stack traces.

I've met multiple "web developers" (actually working on the backend or "full-stack", building API servers and whatnot) who came complaining about this or that server being "unreachable" and could I check it's up / whether the firewall allows them through. Only to find they were getting HTTP 404 errors or the like. Which were explicit in the errors they'd show me.

Re: Write better error messages

#142

Post by vladvasiliu »

outworlder wrote: post #135
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:…

I have managed to get a lot of notoriety in my company by just: 1. Paying attention to error messages 2. Reading documentation 3. Looking up stuff I don't fully understand(including googling error messages) That's it. Some people don't even read error messages at all. I understand non technical people doing that, but I've seen far too many engineers doing it. If anything doesn't go exactly as expected, they freeze. I…

> I'll move mountains to help someone that comes to me after having done some basic homework to try to fix (or at least triage) an issue. It very rare though.

This. I actually am OK with people not figuring out even basic stuff. But please, at least try to give the impression that you've put some effort in, instead of just trying to have me do your homework while you browse facebook or whatever.

Re: Write better error messages

#143

Post by josefresco »

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.

> Stop condescending

Wix is mostly a platform for non-techie DIY website builders. I can't imagine they'd know what to do with a highly technical error.

Re: Write better error messages

#144

Post by Too »

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…

Conversational errors can also be fatiguing. Often what you want is something short and dry that can be pattern matched. Compilers are pretty good at this because all their errors start the same way.

    Error in file foo/bar.c, line 32, missing semicolon.
No conversation needed. These can then be complemented with more conversational language on the next line to explain why semicolon is needed. Rust is quite good at this.

Re: Write better error messages

#145

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

#146

Post by jrochkind1 »

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…

> The reasoning was that "users can't do anything with information we tell them anyways",

I mean, I feel like the focus of the OP was on giving them something they could do something with. Like the information that their information was not lost; and the recommendation to change X or try again in Y way; and the fallthrough to contact customer support with a quick link.

The OP was definitely not recommending giving more specific technical info without thinking about what the user could do with it, but instead specifically thinking about what hte user could do or would want to know (about their data/account, not about your under the hood services), and giving info to that end.

Re: Write better error messages

#147

Post by Jiro »

bonoboTP wrote: post #124
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:…

It's error message blindness, similar to ad blindness. Even if you make a great banner ad with some very useful information, or the perfect and affordable product for my life I won't see it because I mentally filter out ads because they are junk most of the time. Some people develop the same with relation to error messages because most of them are not actionable, other than "stuff broke somehow, [gibberish] blabla".…

There's also the situation where the program creator likes changing functionality on a whim, and every time you google up your problem, you find a solution for a version of the software that doesn't have the particular menu or whatever that you had the problem with.

(This is a big problem if you've ever had a problem with Android.)

Re: Write better error messages

#148

Post by manv1 »

Really, error handling has been my big beef with CS education for like 40 years. There is none.

Error handling has been left to engineers, and when left to they own devices engineers will almost always make the wrong choice from a user point of view.

Engineering need to think of error messages this way: the error message is there to help people (which might be fellow engineers, support, and/or and your consultants) identify the error quickly so that they can manage the user's expectations, fix the error, and/or both.

Unfortunately, many engineering paradigms make this an impossible task.

Layering and encapsulation means that you have little idea what's happening downstream or how the downstream stuff actually works, but the lower-level you are the less likely the error will mean anything to the end-user.

Then, it's a question of who's responsible for handling the error? If you're on the backend, where does it go? Does the user care that the backend microservice can't connect to the database? Heck, the UI probably has no idea what's happening back there.

However, for accurate troubleshooting detail is needed.

For many orgs, leaving transaction IDs in your log files is the primary way that you figure out errors, especially in big distributed systems. That doesn't really help end-users, and requires developer discipline, something many engineering teams find challenging.

Ideally error objects would aggregate error codes up the stack, so that if an error occurs you can at least present technical people with the errors that were thrown..and they can search through the source code trying to find that unique error code. But designing that is difficult; conceptually you don't want a list of 500 error codes being thrown upwards, one from each function in the call chain. But sometimes you do.

Anyway, error handling design really should be part of the initial architecture, but it usually isn't because architecture guys don't really understand support.

Re: Write better error messages

#149

Post by Too »

artogahr wrote: post #95
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.

I don't understand why they wouldn't have a dropdown below the error that would reveal the technical jargon.

They do. Press F12 ;)

Re: Write better error messages

#150

Post by [deleted] »

mceachen wrote: post #125
alisonatwork wrote: post #101

Earlier quoted context omitted.

A useful thing here is not just to include a unique error code for the type of error (usually numeric), but also to generate some kind of short Base32 or similar hash and print that right next to the error message while logging it to your normal back end. Then whether people send you a screen shot, copy/paste, whatever, you can easily search the logs to find the exact event that occurred.

Better still: add a unique prefix to the error code, so it's googlable. The Typescript team does this with compilation errors, like `TS12345: frobulating types cannot be transmuted`.

[deleted]
Post reply on HN