[snapdaddy]

I disagree with nearly every response in this thread (not yours). The 'cutesy' error messages are step 1 to providing a better user experience.

'This is awkward! Something went wrong and it's probably our fault :-('

is much better for users than

'Unexpected error occurred in logTicketResponse'

And no, it isn't sufficient, but it is better. Providing useful error messages is really hard (and it sounds like your application does a good job of it), and we as software developers are not very good at it.

For everyone who complains about the cutesy error messages, how much time are you spending in your own code to provide useful error messages that explain the problem and suggest resolutions?

[Nextgrid]

Absolutely not. A cryptic error message still provides value to the user even if they don't understand it. Not only can they search and ask about it (maybe someone else does know), but they can also figure out a workaround by observing the system and under which conditions the error arises. You don't necessarily need to know what "Error 0x12345" means, but if you notice that it only happens under certain conditions, you can now work around it by not running the system under said conditions.

A bullshit error message on the other hand not only makes searching useless but also prevents the user from exploring towards a solution since they can't even tell different errors apart if they have the same generic message.

[dTal]

They aren't mutually exclusive. The cutesy message also provides useful information (this is our fault, unintended behavior etc). Why not have both?

[mannykannot]

The thing is, cutesiness does not convey anything either useful or specific, and, as this discussion uncontrovertibly shows, may be taken in unintended ways, including as being patronizingly dismissive. This is hardly surprising, as the context in which the error occurs cannot be known to the message's author. One's reaction is immediate and visceral, even if, on reflection, it probably was not intended that way (though I have known one or two developers who always blamed anyone but themselves, and particularly users, for errors.)

[munk-a]

I feel like this is unfortunately a semantic difference only - "cutesy" means different things to different people. Cutesy can just mean "informative but written in a friendly manner" to some people while as you and I understand it to mean "Jovial but unhelpful" - I think the user you're replying to is interpreting it in the first manner. A good example of a "good cutesy" error message might be Chrome's No Internet screen: "It looks like you don't have any internet, here are some ways you might be able to resolve it... but also here's a little dinosaur jumping game to pass the time".

[schwartzworld]

> 'Unexpected error occurred in logTicketResponse'

I prefer this one, despite the fact that users might like the "cutesy" option better. If the user creates a bugfix ticket, the more information the dev receives the better. When you receive a ticket that says "_____ didn't work" and nothing else, how are you supposed to act on that?

When possible, error messages should include _something_ anything to make it actionable. An error code, a descriptive message. Your example tells me exactly where to look in the codebase. I don't care about the verbiage, but generic error messages are almost impossible to reproduce in many cases, and should only be used as a last resort.

[salawat]

...I'll actually write messages that explain what the user may have done wrong and corrective actions they can take...

I believe software should explain itself to the user. Even if the user may not understand.

If you feel uncomfortable telling the User What you're doing, and Why you're doing it, you probably Shouldn't Be Writing It!

If everyone did as much, there'd be entire classes of software (and the ethical bad juju that comes therewith) that wouldn't have been written.

[yibg]

Having a useful error message in all cases requires understanding all possible error conditions in sufficient detail (vs a catch all). Most system don’t have a clear enough grasp of all possible error conditions.

[monkpit]

This is the root of the problem, I think. Especially in JavaScript with the blanket ‘catch’ mechanism and no real good way to have any idea of what exceptions could have even been thrown in the current context.

Obviously the dev will have some idea of which error could have occurred (hence the use of ‘catch’ at all), but it’s not straightforward to enumerate all possible exceptions in that moment, and reason about some subset that should be human-readable, and then come up with some sort of instructions about how to fix the problem.

Maybe that’s the point of the root comment - the exceptions that the dev is trying to catch and prevent from affecting the user should have those human-readable descriptions. And the rest should be silently logged?

But that still just leads to the generic “Well, this is awkward…” errors that you see these days.

It’s a tough topic, and even having the insight of (for example) Java’s ‘throws’ still doesn’t mean the developer explicitly understands the state of the application when those exceptions are thrown (in order to provide some sort of useful message to the user).

[quickthrower2]

“There was a problem loading the QR code. Show this error to a member of staff and they will let you on the train”

Would be pretty cool.

Follow up email with say $1 credit and and explanation later “our technical team is looking right now to fix the problem you had today caused by our systems” would be cool too.

I am glad I read the post to make me think more about errors.

Errors are tricky: an exception can happen in so many different ways in the app and you have to write code to convert some unexpected thing into a bold plan for the user. It is like codifying a crisis leader!

[munk-a]

It's amazing how few companies are unwilling to give away free stuff for errors while also wringing their hands about why accidental errors caused a huge negative PR event - a dollar is probably less than the cost of the CS person spending 15 minutes with the customer on the phone and yet it turns a negative experience into (for most people) a positive one. "Sure we missed our train, but we got new tickets and a bag of chips out of it" is something no one rational would say because it sounds ridiculous, but it is something most people would feel.

[quickthrower2]

This is an interesting point. It is more the gesture rather than the monetary value.

And probably because no one else is doing it. If every bad service you got for everything got a refund then it would be normal and I would think: "meh just a $1 refund again, why don't they damn fix it... shrug".

Tipping is an example where it is really appreciated in non-tipping cultures.

Which speaks to how marketing and "PR" need to keep up with culture and people's expectations today. If you want to exceed expectations that is.