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

211–220 of 265 posts

Re: Write better error messages

#211

Post by golergka »

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…

Also, make sure that sensitive information like user's passwords, emails, credit card numbers etc, is filtered out of the logs and not sent to your servers.

Re: Write better error messages

#212

Post by munk-a »

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 later google tells you that YCOM-HN-9021 is up 9000% you probably broke something. If at all possible make yourself open to client communication but most users won't reach out about an error - users have very low trust in customer care in the modern world (and it is, honestly, often more trouble than it's worth) and are more likely to turn to reddit/technical forums for a solution. It is extremely advantageous to try and track these users.

Re: Write better error messages

#214

Post by dale_glass »

chiefalchemist wrote: post #210
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…

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.

Re: Write better error messages

#215

Post by tiborsaas »

llanowarelves wrote: post #175
tiborsaas wrote: post #67

Earlier quoted context omitted.

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 us…

It's hard to give a generic answer to this. I just see way too many bad error messages that could be solved with a little more thought and copywriting skills.

Error messages are part of the user experience and they should not be an afterthought.

If errors are nested, list them all. Give a generic feedback then, and also provide a technical explanation that would help debugging. Most importantly, we should make the user feel safe and in control as much as possible.

Re: Write better error messages

#216

Post by llanowarelves »

tiborsaas wrote: post #215
llanowarelves wrote: post #175

Earlier quoted context omitted.

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 us…

It's hard to give a generic answer to this. I just see way too many bad error messages that could be solved with a little more thought and copywriting skills. Error messages are part of the user experience and they should not be an afterthought. If errors are nested, list them all. Give a generic feedback then, and also provide a technical explanation that would help debugging. Most importantly, we should make the us…

I actually do like "collecting" the errors when possible, and having them return in the API response (for example). Instead of the common pattern where there's just singular "error:" in the top-level json.

Works great for things like validation.

Re: Write better error messages

#217

Post by wsh »

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 programmer response.

This was more important when messages were practically limited to a single line on a CRT or teletypewriter, and customers had only the printed or microfiche documentation, not online help or websites, but it’s still valuable today.

Re: Write better error messages

#218

Post by layer8 »

> Unable to connect your account

Do they mean “Unable to connect to your account”? Because otherwise it’s not clear to me what this is about. Connect my account to what? This doesn’t read like a user-level concept.

Re: Write better error messages

#219

Post by layer8 »

TacticalCoder wrote: post #203
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 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”.

Re: Write better error messages

#220

Post by rablackburn »

im3w1l wrote: post #194
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…

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.

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 did actually come up in a tech demo or something though. Anything else is tempting the Fates.

Post reply on HN