Write better error messages • Hacker News Board

Re: Write better error messages

#251

Post by randomswede » Thu, Oct 20, 2022, 1:07 PM UTC

Too wrote: post #144

ckozlowski wrote: post #31

Earlier quoted context omitted.

I think you're spot on, and I made a similar comment above. It's easy to say "they can figure it out". Sure, in a restful state. But the people we're asking to take action already have a lot on their plate. Using plain, conversational language whenever possible with exceedingly clear steps means less mental exertion on the receiver. And since we need their help, anything we can do to make it easier on their end helps…

Conversational errors can also be fatiguing. Often what you want is something short and dry that can be pattern matched. Compilers are pretty good at this because all their errors start the same way. Error in file foo/bar.c, line 32, missing semicolon. No conversation needed. These can then be complemented with more conversational language on the next line to explain why semicolon is needed. Rust is quite good at thi…

Then there's the delightful (no, I actually mean the opposite) errors that g++ emitted (back when I last wrote C++ and compiled using g++), where I basically could go "OK, there is an error that was detected at line L, in file F; and I think it may be a type error", so a recompile with clang, so I can actually understand what the error was, so I could fix it.

Re: Write better error messages

#252

Post by matsemann » Thu, Oct 20, 2022, 1:11 PM UTC

cratermoon wrote: post #240

PaulHoule wrote: post #222

Earlier quoted context omitted.

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.

That seems like a good idea, but the problem is that any ID long enough to be sensibly globally unique is likely to be a long string of random-ish characters, and unless the end user has at least a screen cap – highly unlikely – there's about a 0.0001% chance you'll get the code correctly. On the flip side, if you're willing to give up globally unique for "unique enough within and reasonable time frame" then you can…

We did this. Basically showing the semi-unique request-id / correlation-id to the user, or include it in our response headers in our APIs. So when people contacted us with a screenshot or a dump of a request that failed, it was easy to find the exact one in our logs.

Re: Write better error messages

#253

Post by randomswede » Thu, Oct 20, 2022, 1:20 PM UTC

marcosdumay wrote: post #195

chillfox wrote: post #74

Earlier quoted context omitted.

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. bu…

Oh, boy, on the "never log expected failures as errors" front, I once worked with a database system that used opportunistic transactions. Basically, each modification to a row carried effectively the original value of that trow with the update and if it failed, the API call triggered an error saying that the transaction failed. So if you did a "SET column=(column+1) WHERE rowid=unique", the client could basically do an automatic retry.

But, it also logged each and every occurrence of this at "Error" severity, instead of at "Info" severity (it is, after all, expected to happen once in a while).

And of course, once our code switched over to using this, the first few times every team member had to deal with a production issue, the immediate reaction was "oh, no, the data store is unhealthy! look at this mass of error logs, I can see one every few minutes!". Thankfully, after the first team member (me, as it happens) spent half an hour reading the relevant parts of the design and implementation docs, we could frequently short-cut a lengthy investigation by "oh, you think $DB is bad because you are seeing transaction failures? no, that's expected, see $URL".

Re: Write better error messages

#254

Post by PaulHoule » Thu, Oct 20, 2022, 1:41 PM UTC

cratermoon wrote: post #240

PaulHoule wrote: post #222

Earlier quoted context omitted.

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.

That seems like a good idea, but the problem is that any ID long enough to be sensibly globally unique is likely to be a long string of random-ish characters, and unless the end user has at least a screen cap – highly unlikely – there's about a 0.0001% chance you'll get the code correctly. On the flip side, if you're willing to give up globally unique for "unique enough within and reasonable time frame" then you can…

Yeah, just like there is a high fraction of people who can't see 3D movies there are a lot of people who can't cut and paste.

Re: Write better error messages

#255

Post by giancarlostoro » Thu, Oct 20, 2022, 1:53 PM UTC

maleldil wrote: post #197

giancarlostoro wrote: post #196

Earlier quoted context omitted.

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

So is the usual flow to throw these in places where code shouldn't execute but then create tests to try and trip it up to see if that is truly the case? I would hate to be running a release build with this, or does the compiler do something different depending on build type?

Re: Write better error messages

#256

Post by Merad » Thu, Oct 20, 2022, 2:44 PM UTC

mdtusz wrote: post #235

Merad wrote: post #155

Earlier quoted context omitted.

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.

I think this is a symptom of using weakly typed languages as well. If your argument types are declared to be options/eithers, then you need to handle the empty case, but usually it's easier and better to just move that optional handling further up the callstack or type system. A lot of `if (input == null)` checks are because you're just not sure whether the argument being passed in will have a value, and it's too muc…

> A lot of `if (input == null)` checks are because you're just not sure whether the argument being passed in will have a value, and it's too much work for your small feature PR to refactor the whole codebase to resolve it.

Null checks are totally fine, but it should be clear whether or not null is a valid input to the method. If the answer is 'no' then you should throw ArgumentNullException (or whatever's appropriate for the language), not silently ignore the bad input.

Re: Write better error messages

#257

Post by IYasha » Thu, Oct 20, 2022, 7:32 PM UTC

Nice. While working on a large and long-going project, at one point I started redoing all error messages to be more helpful, have implied suggestions and divided by alert levels and categories. Because I decided to take a pause and take care about my users.

Re: Write better error messages

#258

Post by kjellsbells » Fri, Oct 21, 2022, 12:37 AM UTC

randomswede wrote: post #250

wsh wrote: post #217

Earlier quoted context omitted.

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.

Im always amused when I see the HN community get excited about something that the greybeards figured out 40 or 50 years ago. Turns out grandma knew what she was doing after all. If only there was a better way for the wisdom of sages to be transmitted to this generation without eyerolling over IBM and DEC.

Now get off my lawn!

Re: Write better error messages

#259

Post by samus » Fri, Oct 21, 2022, 6:40 AM UTC

dan_mctree wrote: post #199

outworlder wrote: post #135

Earlier quoted context omitted.

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…

This doesn't hold for any popular language. For those, a bazillion tutorials in various formats, books and example projects have been written.

Language documentation is for looking up nitty-gritty details. You go there if you already know what you're looking for. It works for some languages and for some people, but reading it from top to bottom is usually a horrible way to learn a programming language.

Re: Write better error messages

#260

Post by samus » Fri, Oct 21, 2022, 7:27 AM UTC

an_ko wrote: post #130

throw827474737 wrote: post #50

Earlier quoted context omitted.

If it is that simple, the why doesn't the code fix it itself? But no, usually there is 1/2/3 likely things, but it also could be anything else.. and that kind if unexpected errors even often have no default-fix. No, the most best thing is to point to the documentation which has that, and not printig out manpages of docs in error messages now. > I write software that is generally run low in the stack What stack, how l…

I don't want to have to hunt for documentation if it breaks. It may have been 30 years and everything but the binary has been lost, and the vendor is out of business. If in that situation all I get is an error code and a link to documentation that doesn't exist, I'd have to start reverse-engineering. And while doing so I'd definitely be cursing the coder who decided that saving a couple hundred bytes of space in a lo…

Running such software is asking for a disaster already. At least documentation should still exist, and operational frameworks like ITIL insist on that. It can happen, but is usually telling of an operational culture that disregards maintenance, counting on being able to kick the can down the road as long as possible.