Boost logo

Boost :

Subject: Re: [boost] A demonstration of why horrendous error messages can destroy usability
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-12-11 09:15:34

On 12/11/2011 02:29 PM, Gregory Crosswhite wrote:

> Unfortunately, it refuses to build. Why is that? For reasons that apparently took an overwhelming *56 kilobytes of error message* to explain. (See attached, if you dare. )

I'd quite like to see the attached "horrendous" error message, but you
didn't attach anything.

> My point is exactly and *only* the following: horrendous error messages are a *big deal* with a *serious impact*

Indeed, though knowing how to use your tools correctly can go a long way
in lessening that impact.

Compilers are very verbose in diagnosing generic errors because
sometimes that verbosity is needed. Often it isn't.

The most important thing to know is that compilers don't stop at the
first error, but usually the first error is the one causing all
subsequent errors. So you need to look at the beginning and discard the
end. Redirecting stderr to stdout and piping to less is therefore very
helpful so that you don't lose the beginning due to short terminal history.
With GCC, you can also use the -Wfatal-errors flag to stop at the first

Then it is important to know that certain compilers such as GCC start
with the instantiation stack of the error rather than the error message
itself. Again, this is often unnecessary, so just discard it. If you
piped to less, simply type "/error" to search for the first error message.

This is mostly a compiler problem. Various postprocessors and perl
scripts exist to make error messages better. It would be much better if
certain flags could be used to tell the compiler what kind of output to
In the current state of affairs, it's not even possible to tell GCC to
print the full instantiation stack (very verbose, but also very useful
in certain cases). Only clang supports it.

Boost list run by bdawes at, gregod at, cpdaniel at, john at