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

231–240 of 265 posts

Re: Write better error messages

#231

Post by nicbou »

munk-a wrote: post #212

I don't disagree with any points but they missed a big one. If at all possible, include some application (or attempt at a globally) unique error code on each of your errors - i.e. YCOM-HN-9021. When you provide a clearly googleable string you can help your users independently resolve the issue and you can also set up google alerts on the string - if you roll out a new feature that took 3 months to develop and a week…

This is really important if you have multilingual software. It lets users find help in all the languages they understand, not just their OS language.

Re: Write better error messages

#232

Post by nicbou »

TillE wrote: post #93
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've seen this constantly over the years, people who absolutely refuse to read the simplest instructions, but instead require step-by-step hand-holding from you personally. I have no idea how these people get through life at all.

I have no idea either.

For example when someone asks me "how do I get a German work visa" and I reply with a link to a page titled "how to get a German work visa", which is the among the first results on Google. A literal minute later, they ask me more questions that the page clearly answers.

Some people can't be arsed to read a 5 minute article you hand-delivered to them, and would rather have you type it back to them.

I think that some people just have zero respect for other people's time.

Re: Write better error messages

#233

Post by nicbou »

bob1029 wrote: post #154
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 a lesson I learned while being system owner of the primary user interface that runs on a semiconductor factory floor. No amount of confirmation/warning dialogs will actually stop someone from doing a wrong thing. Doesn't matter how scary the language is. Here's an approximate sample of one: "DANGER! Confirming this action may result in 8 figures worth of scrap!!!" Even if you are super careful and make sure y…

I like how GitHub asks you to type back the name of the repository you want to delete.

Re: Write better error messages

#234

Post by trinovantes »

dale_glass wrote: post #131

I'll add a few for developer-oriented messages. * Say what the program was trying to do. * Make the message unique and searchable. * Make it detailed. * FFS, include the filename or whatever else the program is having trouble with. * If possible, include the source code location. * If possible, include useful contextual information. * Quote strings. Once in a while, some unexpected whitespace sneaks in somewhere and…

One thing I've recently started doing when a file related error happens is to retry the command with strace and see which file the program is trying to access

Re: Write better error messages

#235

Post by mdtusz »

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.

I think this is a symptom of using weakly typed languages as well. If your argument types are declared to be options/eithers, then you need to handle the empty case, but usually it's easier and better to just move that optional handling further up the callstack or type system.

A lot of `if (input == null)` checks are because you're just not sure whether the argument being passed in will have a value, and it's too much work for your small feature PR to refactor the whole codebase to resolve it.

Use typescript/python-with-mypy/haskell/rust/whatever and this problem mostly disappears.

Re: Write better error messages

#236

Post by bigiain »

layer8 wrote: post #219
TacticalCoder wrote: post #203

Earlier quoted context omitted.

> Later, on Windows I got this unexpected popup: > > "You are not here" The absolute best I had in a Microsoft product was this (paraphrasing): "An error happened because your computer may be turned off" . I still have a screenshot of that somewhere. What it meant was that an hypothetical computer I may be trying to connect to (which I wasn't, it was all local) was off, but that wasn't the case. This was seriously WT…

The best error message on Windows is “The operation completed successfully”: https://www.google.com/search?q=the+operation+completed+succ... …which is the text for result code zero, which is used to mean “no error”.

“Guru Meditation Error”

Re: Write better error messages

#237

Post by cratermoon »

In my current gig, I would be content if the just has consistent error handling. But for of dozens of endpoints (REST and grpc), there are almost as many different kinds of error responses. Some will return a 400 instead of a 404, some will return a 500 for any error, some will return a sensible error code but the status and message amount to "you called GET on XXX and it failed"

Re: Write better error messages

#238

Post by bigiain »

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…

> The best solution is to aggressively log errors

Until one day you find some random dev is logging failed authentication attempts and including the email and password in the logs…

(and the most amusing part of that incident was tracing down the offender by finding the earliest of those particular log lines, and getting his real email address password out of them… “Hey Phil, what’s ‘Dragons87!’?” “Ummm, what? That’s, errr, my gsuite password. How did you know?”)

Re: Write better error messages

#239

Post by briHass »

munk-a wrote: post #212

I don't disagree with any points but they missed a big one. If at all possible, include some application (or attempt at a globally) unique error code on each of your errors - i.e. YCOM-HN-9021. When you provide a clearly googleable string you can help your users independently resolve the issue and you can also set up google alerts on the string - if you roll out a new feature that took 3 months to develop and a week…

This one helped me recently to access my UPS MyChoice account. Got an error message on login attempt, but really didn't give enough of a darn to waste my time calling their support (as was recommended in the message). Reddit was full of reports with a tip that it was related to forced password reset where the old password doesn't meet new complexity requirements, and I was able to download the mobile app and reset my password.

UPS owes that reddit user a beer for helping out at least 30 people (by up votes) at zero cost to themselves.

Re: Write better error messages

#240

Post by cratermoon »

PaulHoule wrote: post #222
munk-a wrote: post #212

I don't disagree with any points but they missed a big one. If at all possible, include some application (or attempt at a globally) unique error code on each of your errors - i.e. YCOM-HN-9021. When you provide a clearly googleable string you can help your users independently resolve the issue and you can also set up google alerts on the string - if you roll out a new feature that took 3 months to develop and a week…

Another one is to generate a globally unique id for that failure. In a web application the user can share the id with you and you can look in the log and see the associated error.

That seems like a good idea, but the problem is that any ID long enough to be sensibly globally unique is likely to be a long string of random-ish characters, and unless the end user has at least a screen cap – highly unlikely – there's about a 0.0001% chance you'll get the code correctly.

On the flip side, if you're willing to give up globally unique for "unique enough within and reasonable time frame" then you can go with just a few characters or even short words.

Post reply on HN