[lkml]   [1999]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Profanity in the Linux Kernel?!?!?
    Hi Kai.

    >> a misleading or ambiguous error message is worse than no
    >> error message at all in my experience.

    > Let me go on record as violently disagreeing, here.

    > A bad error message is still something you can track down. Even
    > if it's bad, you know that execution reaches the point where it
    > gets printed, and you can backtrack from there.

    If you can backtrack to the actual error, you're extremely lucky in my

    > No error message and you have not even that.

    The result being that you normally have just as much idea where the
    error actually is in both of the above cases - ie, none whatsoever.

    > In fact, in my experience, about a third of all error reports
    > are misleading anyway, even given the most careful messages, and
    > there's nothing you can do about that.

    In my experience, error reports can be broken down into the following
    four categories:

    1. Syntax errors, or errors of coding that prevent the program
    from compiling correctly. These are all detected straight away,
    and are the easiest errors to fix.

    2. Linking errors, or errors that permit the program to compile,
    but prevent it from linking into a valid executable. These are
    also detected straight away, and are the next easiest errors
    to fix.

    3. Trapped logical errors, or errors for which the program checks
    at the point where the error may occur. Because they are trapped,
    these errors are relatively easy to fix as one knows exactly
    where to look for the error based on the error message. As a
    result, most programs over 6 months old have few of these left.

    4. Untrapped logical errors, or errors for which no check is made
    by the program at the point where the error may occur. Because
    they are NOT trapped, these errors are extremely hard to locate.

    Errors in the first two categories can basically be ignored as far as
    this discussion is concerned, and in my experience, the split between
    the last two categories tends to be 25% for (3) and 75% for (4), and
    the easiest way to determine which category they're in is by how clear
    the error message is.

    Difficult to understand error messages are inevitably also old ones,
    usually ones that made sense when they were first written, but for
    which their original meaning no longer applies, and their appearance
    generally indicates an error in category (4) for which the only thing
    one can safely say is that the actual error will be nowhere near the
    error message.

    On the other hand, an error message that's easy to understand usually
    indicates an error in category (3) and thus one that's easily tracked
    down and fixed.

    Personally, I'd love to see something along the lines of a kernel
    orientated assert() macro inserted throughout the kernel, with the
    property that if the condition listed therein was false, it reported
    the fact to some systrace facility (perhaps using syslog) so one could
    use that as an additional aid when tracking down problems. If it was
    implemented properly, then the ONLY reports it produced would relate
    to assumptions kernel writers both made and documented that were not

    Best wishes from Riley.

    | There is something frustrating about the quality and speed of Linux |
    | development, ie., the quality is too high and the speed is too high, |
    | in other words, I can implement this XXXX feature, but I bet someone |
    | else has already done so and is just about to release their patch. |

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.024 / U:16.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site