Write better error messages • Hacker News Board

Re: Write better error messages

#221

Post by redbell » Thu, Oct 20, 2022, 12:08 AM UTC

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…

There's also that hilarious Windows Phone error that prompts users to insert their Windows installation disc and restart their "computer".

Re: Write better error messages

#222

Post by PaulHoule » Thu, Oct 20, 2022, 12:09 AM UTC

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.

Re: Write better error messages

#223

Post by wavesquid » Thu, Oct 20, 2022, 12:16 AM UTC

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…

With the important corollary that you need to check for the errornous condition both early and late.

Otherwise people start e.g. checking in the frontend and don't enforce it in the backend in the worse case, or TOCTOU bugs in the best case.

Re: Write better error messages

#224

Post by xboxnolifes » Thu, Oct 20, 2022, 12:17 AM UTC

mariusmg wrote: post #17

zagrebian wrote: post #8

Earlier quoted context omitted.

This just means that the error message needs to be more clear. For example, after the error itself, it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to . Set ENVVAR to a proper value and restart the service.” Notice the direct language. It reads like an order. The less direct the message, the higher the chances that the user will not act upon it.

>it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to . Set ENVVAR to a proper value and restart the service.” Really, should logs also be documentation now ? Just mindlessly logging the same "advice" over and over again each time the error happen ?

Should logs more clearly let the user know how to fix problems? Yes.

Re: Write better error messages

#225

Post by PaulHoule » Thu, Oct 20, 2022, 12:21 AM UTC

It reminds me of an article from Byte magazine back in 1981, but the basics stay the same.

I'd like to learn how to make more meaningful error messages in compilers, particularly "low code" compilers that slice code transformations thinly and thus have a hard time explaining which lines of code are interacting to create this situation that happens at phase 39.

Re: Write better error messages

#226

Post by redbell » Thu, Oct 20, 2022, 12:24 AM UTC

This reminds me of the two most annoying error messages of all time [for me].

The first one is from PayPal. Whenever I try to add a US bank account to my PayPal account, it says something like "You cannot add this bank account at this time, period"

After more than a year, it turned out that there was no way to add such an account for a foreigner, despite my friends [from the same country] being able to do it easily a couple of months before.

The second one is, poor me again, trying to edit a Facebook page URL I created for a side project, that should read FB.com/[SIDE_PROJECT], where FB keeps rejecting my request with a generic/ unexplained/unhelpful error message despite the page URL name was available.

About a year later, I got it working by, SIMPLY, having my phone number verified! How bad!!

Re: Write better error messages

#227

Post by andirk » Thu, Oct 20, 2022, 12:35 AM UTC

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…

ESLint complains if no `default` option on `switch` statements. Sometimes it's not possible. I have been trained to add it regardless. While developing, I add some message like "not possible" and sure enough it hits once in a while in dev due to something I didn't consider.

Re: Write better error messages

#228

Post by andirk » Thu, Oct 20, 2022, 12:38 AM UTC

Please also put variable names at the end of sentences when possible. For example, instead of "Your file /user/foo/bar.baz did not load correctly because of whales", how about "This file did not load correctly because of whales: /user/foo/bar.baz". The search is much easier.

Re: Write better error messages

#229

Post by drpixie » Thu, Oct 20, 2022, 12:56 AM UTC

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…

Yes to all - and also don't include boilerplate text, or at least limit it to the minimum polite for your audience.

So if you must show a stack dump:

- don't put in lots of whitespace - it might look pretty but it makes it harder to read/parse.

- if you're giving the error file:line, don't bother showing the source code. If the source is meaningful to the reader, they've probably got access to the code, or are using an IDE.

Re: Write better error messages

#230

Post by Aeolun » Thu, Oct 20, 2022, 1:01 AM UTC

rablackburn wrote: post #220

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.

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.