Hacker News new | ask | show | jobs
by kstenerud 1835 days ago
> In error checks that detect “impossible” conditions, just abort. There is usually no point in printing any message. These checks indicate the existence of bugs. Whoever wants to fix the bugs will have to read the source code and run a debugger. So explain the problem with comments in the source.

But then the person RUNNING the program will only see this:

    Abort trap: 6
And that's all the info you'll get from their bug report.

So please ignore this directive and print a descriptive message always, complete with file and line, and the values that led to the impossible situation. Then you can get helpful bug reports like:

    BUG: flush.c:51: buff_offset (65535) must not be greater than 20!
    Abort trap: 6
1 comments

It's hard to imagine that directive lasting beyond the first bug report of "it broke, fix now!".
The core dump contains information for fault analysis.

There is another aspect, C and C++ are not memory safe languages so the bug may not be particular logical (i.e. some kind of memory corruption). In these cases I actually prefer something to the like of __builtin_trap instead of abort. Calling any code after an invalid invariant has been detected clobbers registers and may make it impossible to investigate the state at the time of the "crash". Some features of modern optimizing compilers make this even worse, such as abort being marked as "noreturn".