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

201–210 of 265 posts

Re: Write better error messages

#201

Post by m-p-3 »

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…

I'll also add to make them easy to copy to clipboard in the case of a GUI-based program.

It's easier to search and store in an incident management system.

Re: Write better error messages

#202

Post by m-p-3 »

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 epitome of uselessness: making an error message so "user-friendly" that it doesn't help anyone.

At least a "Details" button to unmask the technical details would be useful in some way, while hiding the "ugliness" to the end-user.

Re: Write better error messages

#203

Post by TacticalCoder »

Stratoscope wrote: post #186

20 years ago I was working on Acrobat at Adobe. I was mostly the "Windows guy" but also worked and tested on the Mac. When I tried to install Acrobat on my Mac, I got this message: "Your hard disk is too small" My what is too small?! Later, on Windows I got this unexpected popup: "You are not here" WTF? I searched the code for that string and found it in a function named "CantHappen()". This function was called in nu…

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

The second most beautiful one from another Microsoft product was whatever software generating a password and asking me, in a pop-up window, to write it down. The problem was the password was something like:

    9mZOvy9E(4)?6b(w(9T6cz0Z4YxgQ-2:G>%*P]7n4"
I probably also still have a screenshot of that somewhere.

Haven't used Microsoft stuff in two decades so it was a long time ago. But it's still seriously WTF.

Re: Write better error messages

#204

Post by lucb1e »

marklubi wrote: post #87
nkrisc wrote: post #82

Earlier quoted context omitted.

The goal of writing better error messages isn't to help the people who never read error messages, it's to help the people who do and who you never have to hear from.

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.

> each error message needs to be unique

Include random numbers. "Error 7743929" is super easy to track down (grep -r 7743929 takes 2 seconds to type), you don't need a NATO alphabet to understand what they're saying on the phone in order to be able to search it correctly, its general purpose is understood internationally, and it won't change between versions (like when you'd encode a file name and line number, for example). When I first figured this out at, idk, 17 years old and mentioned the idea in a game making forum, people called me crazy, but I still use it and don't know of any better system.

Of course, this is alongside an actual error message to help the user help themselves. This is just to trace the line where it originated, which already helps a lot for small software projects like I make.

Re: Write better error messages

#205

Post by redact207 »

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…

For Saas products, this plus use structured logging so you don't have to grep-parse log messages when searching your log collectors.

Ie all the meta/log context in a hashmap alongside the error message.

Re: Write better error messages

#206

Post by remram »

giancarlostoro wrote: post #196
im3w1l wrote: post #194

Earlier quoted context omitted.

The paradox of CantHappen is that if the programmer truly thought it can't happen then there would be no need for it in the first place. The only reason to include it is because of a fear that it may in fact happen. Rust funny enough has unreachable()! for that case, but it also has unreachable_unchecked() for actually unreachable code. The latter has undefined behavior and exists to help the optimizer.

What does unreachable()! do actually? I had no idea that was a thing.

Rust has a few of those, they all panic but with different default messages: panic!(), todo!(), unimplemented!(), and unreachable!()

Re: Write better error messages

#207

Post by [deleted] »

marklubi wrote: post #87
nkrisc wrote: post #82

Earlier quoted context omitted.

The goal of writing better error messages isn't to help the people who never read error messages, it's to help the people who do and who you never have to hear from.

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.

[deleted]

Re: Write better error messages

#208

Post by fleddr »

This is great, I would add one critical ingredient: provide actual customer care.

Meaning, the "way out" is to point users to customer care, but this still does not help if customer care is shit. And we know it often is.

Customer care should be an email address (and/or phone number) in the footer. Not a contact form. Self-help/FAQ is fine, but no replacement for direct contact. Nor is a shitty AI bot.

And when contacting support directly, answers should not be scripted non-sense completely ignoring the actual issue at hand.

I don't care if it doesn't scale. Make it scale. Your problem.

Re: Write better error messages

#209

Post by frontiersummit »

londons_explore wrote: post #113

How about just engineering stuff to not have errors in the first place. My toaster is a complex bit of engineering - it has thousands of parts which all work together to take power from the wall to make toast. Yet it has no errors. It just does the job I ask it to do. A computer on the other hand seems to have a lot of ways to fail, and does so nearly every day. I suspect everyone reading this comment has seen at lea…

A toaster is probably a bad example, given the common error states (burnt toast, stuck toast) which are no doubt amplified by design flaws in some units. I've never seen a toaster with 2000+ components, so maybe such a machine is different. A toaster is also historically famous for a dangerous error state: if the plug is inserted the wrong way round, the coils will be switched on neutral. A toaster which is "off" is thus liable to shock an unwitting person using a fork to resolve the stuck-toast error state.

Re: Write better error messages

#210

Post by chiefalchemist »

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…

A couple+ years ago my then employer required I take (what amounted to) Security Training 101 for Software Developers. I believe one of the client orgs expected everyone to go through the program.

That said, Ppetty much everything you're suggesting was considered a bad idea (for security). Mainly because the more details you give away, the more a hacker can understand about the underlying system. The more they probe and possibly break things, the more you're showing your cards.

It was then the bland cryptic error msg made perfect sense to me.

Post reply on HN