Write better error messages • Hacker News Board

Re: Write better error messages

#191

Post by at_a_remove » Wed, Oct 19, 2022, 8:03 PM 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…

Yup, all of these. Sometimes I look "around" the problem, like, "I found THIS directory but the file 'z.txt' was not in it!" or "Not only could I not find 'z.txt' I could not find THIS directory it was supposed to be in." Check to see that it is really a file, not a directory. "I found 'z.txt' in THIS directory but it was zero bytes in length!"

In terms of "fail early," my larger programs have a section called Pre-Flight Checklist, which looks for files (and that they are files), databases, that the databases have the expected tables and the correct columns, and so on. Are the files sufficiently recent? More or less the expected length? Because this is ETL stuff, it's usually okay to push this stuff up as early as I can.

Re: Write better error messages

#192

Post by Terr_ » Wed, Oct 19, 2022, 8:29 PM UTC

Over time I've come to believe in the "grepability" of error messages, and the code-lines that construct them.

Sometimes the data (and error-messages) are flowing up and down through many different modules and APIs and job-queues and whatnot, that when an error pops up it saves a lot of developer-time when you can just text-search on the code repo(s) and see exactly the line that generated it in the first place.

Re: Write better error messages

#193

Post by elboru » Wed, Oct 19, 2022, 8:31 PM UTC

Merad wrote: post #155

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…

This is an attitude I really try to build up in junior devs. Soooo many people seem to default to writing code like, "if input is null return null" (when input should never be null) or "if valueThatShodBePositive I guess this is because no one really teaches error handling. I assume a lot of students end up with a mindset of just make the errors go away instead of, deal with the errors effectively.

When I was a jr dev, getting exceptions was a synonymous of ”me messing something up”. Null exceptions were specially annoying, so the naive approach is to check for nulls and avoid the code that will cause the exception. And it “works”! You don’t get exceptions and your code keeps running. It’s just when you need to fix difficult bugs while you go through logs when you understand the value of having the right exception with the right message. And you learn to love them and start caring about them.

Re: Write better error messages

#194

Post by im3w1l » Wed, Oct 19, 2022, 8:34 PM 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…

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.

Re: Write better error messages

#195

Post by marcosdumay » Wed, Oct 19, 2022, 8:37 PM UTC

chillfox wrote: post #74

starkd wrote: post #71

Earlier quoted context omitted.

I admit to doing this. Even many of the useful error messages that clearly indicate the fix are drowned out out by the mass of output. I've made this mistake before, and I'll probably do so again.

I feel like this is a problem of overly chatty application logs + lack of formatting for errors. If the volume of drivel was lowered and errors were formatted with spacing and color to stand out, then they would be easier to focus on. So log errors to stderr, send it to a separate log file, and format it well (use multiple lines).

> So log errors to stderr, send it to a separate log file, and format it well (use multiple lines).

Oh, for sure. Do never:

- send errors to the same log you send normal activity.

- default into logging things that aren't errors on the error log (make this possible to override if you want, but never the default).

- log the errors there, but the necessary context on stdout so it appears correct on a terminal. (E.g. build tools that print entering into target in stdout; error in stderr; leaving target in stdout)

- try to recover just to show a different error later.

Re: Write better error messages

#196

Post by giancarlostoro » Wed, Oct 19, 2022, 8:55 PM UTC

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.

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

Re: Write better error messages

#197

Post by maleldil » Wed, Oct 19, 2022, 9:14 PM UTC

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.

It terminates the program with panic!

https://doc.rust-lang.org/std/macro.unreachable.html

Re: Write better error messages

#198

Post by jdiez17 » Wed, Oct 19, 2022, 9:24 PM UTC

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…

I don’t know what kind of toaster you have but mine doesn’t have thousands of parts. Maybe 20 or so.

Re: Write better error messages

#199

Post by dan_mctree » Wed, Oct 19, 2022, 9:30 PM UTC

outworlder wrote: post #135

hprotagonist wrote: post #3

I would, if i had any evidence at all that they would be read and acted on. I’m convinced even seemingly competent people are just rendered contextually blind by the appearance of any error at all. In the past month, i’ve had about a dozen interactions like this: developer: your service crashed, here’s a screenshot of the last 5 lines of the crash me: do you see where the final text you just pasted is “RuntimeError:…

I have managed to get a lot of notoriety in my company by just: 1. Paying attention to error messages 2. Reading documentation 3. Looking up stuff I don't fully understand(including googling error messages) That's it. Some people don't even read error messages at all. I understand non technical people doing that, but I've seen far too many engineers doing it. If anything doesn't go exactly as expected, they freeze. I…

> except that he continued to not read the language documentation before asking a bunch of questions

Can't really blame people for that too much, most language documentation is utterly unreadable unless you already know exactly what you're doing. And even if you do get it, it's in one eye and out the other. Most people just don't learn very well from reading technical information you don't need to use right away. You might be a happy exception and got to build up your notoriety that way

Re: Write better error messages

#200

Post by andrewguenther » Wed, Oct 19, 2022, 9:35 PM UTC

Bonus points if your link to customer care auto-populates the fields necessary to get the ticket where it needs to go and can attach relevant diagnostic information to the resulting ticket.