Hacker News Reader

Comment by bookofsand | Hacker News Reader

No, developers don't read compiler error messages, unless absolutely necessary. The economics doesn't work out: the compiler creates hundreds of error messages in a few milliseconds, whereas developers only have a very limited budget of attention.

What developers do is to check where the errors show up, usually just the first error, and use pattern recognition techniques, aka 'experience', to fix the error in its context. Only if the fast track error recovery process fails, repeatedly, do developers spend minutes to carefully read the compiler error messages and deeply make sense of it.

This matches the article thesis: the 'better' compiler messages are, the more likely is that pattern recognition techniques can use the error message as part of the fast track error fixing process.

View on HN

> No, developers don't read compiler error messages, unless absolutely necessary.

This depends fully on the ~language~ compiler.

Some compilers create extremely long verbose but useless messages, other create use-full messages most times only as long as necessary with nice formatting making it easy to skip over the parts you don't care about.

Like e.g. I always read error messages when programming rust, sure I fix a error at a time so I don't read all error messages at once, but I do go through them step by step.

With Rust specifically, but also with many languages in general, it's important to read the errors from top-to-bottom because the errors become more and more absurd as they go down.

For example, if there's an error in a macro that was meant to emit a trait impl, the first error will tell you about the error in the macro, and then the fifty errors after that will be fifty different and increasingly confusing ways of telling you that the type doesn't impl the trait.

If you don't start at the top and fix one error at a time you'll just end up chasing and being confused by red herrings.

This is a real thing that rustc does, but we do try to put effort into silencing errors that are caused by earlier ones. If this happens often to you, I would kindly ask for bug reports because I would love to avoid this from happening.

Clang (and modern GCC) warning are quite helpful, but they are ignored because by default they don't break a build (and only a small fraction of C/C++ projects use -Werror). If ignored they may cause problems later when an app will be used. Or may not cause any problems at all - that the case for subpar code in general - it is more likely, but not guaranteed to break.

-Werror can be hang up development at times, which is why we don't use it with Ardour. Sometimes, it can take a while to understand why some obscure message from the compiler is actually relevant and actionable, and that's not always the main focus while working on features or fixing a specific bug.

However, we do have a policy of expecting that all compiler errors (except those in in-tree 3rd party libs) should be fixed. We take a very negative view of any commits that create new compiler warnings. Essentially, we prefer to have a development culture that treats warnings as errors rather than have the compiler enforce warnings as errors.

When building Ardour, we this as a minimum:

'-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter'

but prefer to use this:

'-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-Wcast-align', '-Wextra', '-Wwrite-strings', '-Wunsafe-loop-optimizations', '-Wlogical-op', '-Wnon-virtual-dtor', '-Woverloaded-virtual', '-fstrict-overflow'

For small teams that may work, but at some point, you need to protect yourself from tragedy of the commons. This is especially true during growth periods in the team or periods with significant churn. Culture can very easily shift and having something other than humans involved in ensuring good habits are held is worthwhile.

Something I've never seen recommended - while more information is better up to a point, error messages that are oddly phrased, not uniform with all the others, etc. are kind of a good thing, because they're easier to recognize and search for by a distinctive fragment.

In effect, good writing can have negative returns.

It doesn't happen that often, but sometimes I get frustrated searching for an error that shares its wording with way too many unrelated issues.

[I am thinking more of runtime errors, but still]

In the old days errors came with error codes. This helped searchability using an index in a printed manual, but also Google. Unfortunately people are not good at pattern matching random many digits numbers, so this is not very useful in the front line. I wonder if world triplets, possibly semantically meaningful, could be used as error codes of sorts in the compiler error space.

Reply on news.ycombinator.com