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

171–180 of 265 posts

Re: Write better error messages

#171

Post by InCityDreams »

taink wrote: post #36
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 think the point they are making here is that clearly stating what went wrong doesn't necessitate using "technical jargon". Now, "your credentials have been denied" seems pretty clear and does not use jargon in my opinion, but telling the user "the ajax request failed, returning a 403 http error code" seems unhelpful and doesn't tell them what happened.

...then they clearly didn't make their point at all. Big error (in communication) on their part. Your single (2nd) sentence communicates everything required.

Re: Write better error messages

#172

Post by hulitu »

e40 wrote: post #165

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

You shall be happy that you got an error message from Google because their default is not to give any.

Re: Write better error messages

#174

Post by marcosdumay »

cogman10 wrote: post #117
wongarsu wrote: post #116

Earlier quoted context omitted.

That seems like peak uselessness. Even "Error code 0x00ad4829" is a more useful message, because even if it's useless to the user it is useful to somebody .

There is some logic, the "you don't want to expose your internals". Really useful messages might contain a lot of details about the tech stack you use (giving a nice hint into which CVEs to try). That said, this is an easily solved problem. The best solution is to aggressively log errors AND prioritize having dev teams push that error count to 0. If an error happens, it's a bug. The next way to solve it is simply a r…

> Really useful messages might contain a lot of details about the tech stack you use (giving a nice hint into which CVEs to try).

Nope. Useful messages contain details about what your software does. Anything about your tech stack is redundant and can be removed.

> The best solution is to aggressively log errors AND prioritize having dev teams push that error count to 0.

Many errors can only be replicated talking to users. And on the cases your dev team is not all capable enough to remove all errors, you will still want to provide customer support and work-arounds.

> The next way to solve it is simply a report button.

A report button is good. But neither session ID nor any data that you can reasonably add to your logs will be enough to let dev know what went wrong. Besides, your report button will have errors too.

And anyway, anything that you said applies exclusively to people that create web applications. Many other types of application exist, and everybody writing them are better off not following any of your recommendations.

Re: Write better error messages

#175

Post by llanowarelves »

tiborsaas wrote: post #67
madeofpalk wrote: post #65

Earlier quoted context omitted.

I think the point is that the higher up you fail, the harder it is to identify why you errored in order to give the user clear and actionable feedback.

That's possibly indicating a bad UI / information architecture if you are unable to tell that.

When you have nested exceptions being caught by other exceptions, how do you determine what level is correct to show the user? Especially when it's a service class or something that is used by a lot of calling code.

It's implied that it would be the upper top-most exception handlers in that code path but those are gonna be more generic in their messages, and anything more detailed has to be manually wrapped to add useful description (that's not some internal developer exception).

Error codes may be the least bad solution, to fallback on.

Re: Write better error messages

#176

Post by berkes »

cogman10 wrote: post #117
wongarsu wrote: post #116

Earlier quoted context omitted.

That seems like peak uselessness. Even "Error code 0x00ad4829" is a more useful message, because even if it's useless to the user it is useful to somebody .

There is some logic, the "you don't want to expose your internals". Really useful messages might contain a lot of details about the tech stack you use (giving a nice hint into which CVEs to try). That said, this is an easily solved problem. The best solution is to aggressively log errors AND prioritize having dev teams push that error count to 0. If an error happens, it's a bug. The next way to solve it is simply a r…

Why are error codes a terrible solution? I rather have an error "bad request f12793b2" than a "bad request". Obviously I prefer a "bad request, 'expiresAt cannot be after 2022-12-19'. Code f12793b2".

Having a unique ID to be able to search in documentation or even source code is -IMO- preferable. It's still rather technical and helps only those who can search such docs, but at least it gives something unique to google/search for."

Re: Write better error messages

#177

Post by he0001 »

I believe that any language that treats errors and error management as an afterthought are bad. Also any programmer that treats errors as an afterthought or simply ignore them is going to write bad code/programs. Errors are hard and need language first level support. People talks about “higher order functions” but never how to deal with errors (mainly because it’s boring and complicated). Also errors are tightly coupled with intentions, as if you fail to do something, well that’s an error. But that also means that it’s tightly coupled with what the program is trying to achieve. So anywhere an error happens should be close to what it tries to do. Also it solves what an error is all about, which makes it easy to describe what it should be. Yes there are errors that may not fall into this category as they are much less related to what you are trying to do functionally. Any program which ignores how errors work and flow, in my experience, has always been bad in general, as the structure of it is also bad as there’s no organization.

Re: Write better error messages

#178

Post by kgeist »

What the article is missing is how they learned the new error messages are now more helpful to the end user. Some kind of metrics: maybe, the number of support tickets/angry reviews decreased? Otherwise without clear criteria for success I'm not sure if it was worth it and wasn't just changing the error messages for the sake of changing. Sure what they talk about makes sense but "it makes sense" is not a business metric.

Re: Write better error messages

#179

Post by _nalply »

It is my opinion that software problems tend be analyzed corresponding to these four axes:

- Can an end-user solve the problem themselves? If so, tell them how, if not, display a generic error message telling them to ask for support (with an error identifier they can tell the support)

- Developers and end-users need different information: developers need as much information as possible, like file names, contents of important variables and especially where the error happened in the source code with a backtrace, sometimes even two backtraces: the backtrace for the cause of the error, too; and end-users only need to be told what they can do, but this needs to be worded clearly and carefully. This means that error messages need to be written twice.

- Is the problem serious? If so, report, crash and restart, if not, just report and abort the affected operation when neccessary.

- The problem should be logged. Sometimes it can be sent to developers automatically.

Re: Write better error messages

#180

Post by shadowgovt »

legulere wrote: post #100
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.

In RFC 7807 all errors get an unique URI. Message texts might change or be translated into a language you don’t understand.

It turns out translating error messages is controversial.

Users, upon hitting an error, often go check Stack Overflow. If you localize your error messages, you Balkanize the collective wisdom on how to address the error (which will always be larger than your team's ability to troubleshoot errors and offer correctives in your documentation and FAQs).

Post reply on HN