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

241–250 of 265 posts

Re: Write better error messages

#241

Post by cratermoon »

Aeolun wrote: post #230
rablackburn wrote: post #220

Earlier quoted context omitted.

I’m guilting of writing a “can’t happen” branch (as I’m sure many of us are). I stripped it out before production after verifying it couldn’t actually happen but it was something like an artefact of my thinking process while writing the code. It feels like a kind of assertion of underlying assumptions, and I know enough to know I’m fallible. I’m always careful to make the error message something reasonable if it ever…

I don’t understand why the message would be ‘Can’t happen’ in the first place. I’d always make it something like “If you see this, something entirely unexpected went wrong.” Showing and triggering the error is helpful in itself since it’ll generate a trace and all the attendant stuff.

"lp0 on fire" and "PC LOAD LETTER" are two good ones, too.

Re: Write better error messages

#242

Post by worik »

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 developers, maybe. But they need logs, not error messages.

For users they need brief, is it fatal (restart) temporary (try again) or just this part - do something else.

Adding words is unhelpful. More information means less communication.

Re: Write better error messages

#243

Post by joshka »

3 things I'd add (and have used with success):

1. Always have an error specific URL to point at. Changing a document stored outside the system is often significantly easier than redeploying a system (order of magnitude seconds or minutes vs. hours or days in the worst case). There are many benefits to this approach. It's available when your system is not. It's possible to look at metrics and collect NPS scores on the information. It's easy to add pictures, steps, links etc.

2. Try to add an operation specific correlation ID. This allows the user to talk about a specific instance of an error easily when dealing with support and developers to look for specific log info. This is also useful if you provide a 'get support' link on errors that require manual intervention.

3. Add an error specific identifier to help developers map error strings back to source code. Often with error messages that are string interpolated the unique values tend to obscure the non-unique parts of the message. Also messages that are fairly similar can make it more difficult for a developer to find the specific cause.

These are not alternatives, but additions to TFA's suggestions.

Re: Write better error messages

#244

Post by dejj »

wsh wrote: post #217
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…

IBM has done this for decades. For many products, especially on the mainframe, every message has a unique identifier, typically with a prefix for the module or subsystem that generated it, a message number, and an action or severity code, such as “I” for information or “E” for error. A series of Messages and Codes books is supposed to list every message, each with an explanation and suggested user, administrator, or…

Error -41: sit by a lake

https://xkcd.com/1024/

Re: Write better error messages

#245

Post by franga2000 »

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…

If you do this, please make it alphanumeric, like the above comment's example and make sure your prefix is unique. Modern search engines, especially Google, are very bad at finding literal strings if searched without quotes (many users don't know to do that) and have all sorts of gotchas that make finding errors near impossible.

Some bad examples (both from Microsoft): - "Code -4" (putting a minus in front of a word makes Google exclude that word from results), - "0x00071153" (search engines love to omit the 0x and give you a bunch of phone numbers instead)

Re: Write better error messages

#246

Post by bob1029 »

nicbou wrote: post #233
bob1029 wrote: post #154

Earlier quoted context omitted.

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.

For GitHub scary actions, I will not hesitate to copy and paste the expected repo name on the UI. I can do this so quickly my brain does not process the consequences in time.

Re: Write better error messages

#247

Post by stormking »

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.

Just use both. A globally unique but static "error code" to google plus a serial number of that distinct instance of the failure.

Re: Write better error messages

#248

Post by chiefalchemist »

dale_glass wrote: post #214
chiefalchemist wrote: post #210

Earlier quoted context omitted.

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…

Well, everything is depends on context of course. I'm talking here mostly of user-facing local applications -- like what would be in your mail client's logs, or the logs of a corporate service, where the logs are there for the admin's/dev's use. Of course if you're sending feedback to a potential attacker things change considerably.

I understand. But I'm going to assume the rule would be. Do X. No exceptions. As you know, doing sec means living with a healthy amount of paranoia. Imagine giving an exception and being wrong.

Sec = better safe than sorry.

Re: Write better error messages

#249

Post by A_Venom_Roll »

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

Long time ago I ran into a "catastrophic failure" in Word, which sounds quite serious.

Re: Write better error messages

#250

Post by randomswede »

wsh wrote: post #217
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…

IBM has done this for decades. For many products, especially on the mainframe, every message has a unique identifier, typically with a prefix for the module or subsystem that generated it, a message number, and an action or severity code, such as “I” for information or “E” for error. A series of Messages and Codes books is supposed to list every message, each with an explanation and suggested user, administrator, or…

Likewise Digital, all VMS error codes are "SUB-S-NAME" (so a permissions error when dealing with a file woule be something like "%RMS-E-NOPERM" (I think that's "rotating mass storage" rather than "Richard M. Stallman"). I think that even harks back to various OSes on the PDP-11, but cannot say for sure.
Post reply on HN