This is an oft-repeated meditation, but we can all use a little reminding now and then.

In a production system, error-checking and logging are not optional activities. They are an essential component of its health and continued operation. In a way, they go hand-in-hand.

Error-checking should be done on every single untrusted value that enters a sub-routine. Every check that fails should log an error. Potentially, an error should be thrown, possibly even a fatal one.

An untrusted value is one that comes from a source that is not a subroutine you wrote yourself. A non-exhaustive list would include:

  1. User input. Users are the immediate cause of 99% of all errors in a program. (The real cause is poor programming.) The darned things seem to find every case you didn't account for. It's almost funny, sometimes.
  2. WWW input. This is user input, but it's a special case cause people seem to have this notion that stuff off the WWW is somehow going to be perfect. It's not.
  3. Modules. Just cause merlyn wrote it doesn't mean it works. He's human, too, you know. In addition, the module might have encountered an error condition and is returning that value to you to indicate what happened.
  4. Built-in functions. How many times have you seen someone write: 
    open HANDLE, ">myfile";

    [download]
    What if there is no space on the drive? The program will crash the first time HANDLE is written to, cause it wasn't opened successfully.
  5. Databases (and other stored data). Just cause you wrote it doesn't mean someone else didn't change it behind your back.
Yes, it is theoretically possible to overdo error-checking. I've never seen that happen, though. I love seeing functions with 100 lines of error-checking and 20 linse of actual work. They give me warm fuzzies.

As for logging ... it's usually the only way you know what your program has done. When I write something, it spews out tons of crap onto the screen. 99% of it, I will never use. 99% of the time, I won't use the other 1%. That 1% of the time ... My! how that 1% of the logging has saved me days of work. (No exagerration!)

Newer programmers seem to have this idea that logging and error-checking are both a waste of time. On the contrary, they are the greatest time-saving tools we as programmers have! Ask any person who's been programming for more than five years. Heck, even hackers do it. :-)

Update: Added databases to the listed of untrusted sources as per scain. Thanx!

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Replies are listed 'Best First'.
Re: Error-checking and logging
by mirod (Canon) on Feb 26, 2002 at 16:46 UTC

    While I generally agree with you on the importance of logging, I have a couple of comments:

    A minor one first:

    Built-in functions. How many times have you seen someone write: open HANDLE, ">myfile"; What if there is no space on the drive? The program will crash the first time HANDLE is written to, cause it wasn't opened successfully.

    The problem is not usually a lack of space on the disk, 99% of the time it is with user rights: the file you want to write already exists and is owned by someone else.

    Then something a little more philosophical:

    As for logging ... it's usually the only way you know what your program has done. When I write something, it spews out tons of crap onto the screen. 99% of it, I will never use. 99% of the time, I won't use the other 1%. That 1% of the time ... My! how that 1% of the logging has saved me days of work.

    I don't know about that. Code that fills the screen with useless log/warning info is just likely to make you miss the one message that was really important and that should have gotten your attention. Instead it got lost in the flow of usual crap that your program generates. So unless I can also provide the user with tools to filter the output, I usually stick to outputting only the most important warnings, while providing ways to generate additional logging if need be.

[reply]
[d/l]
      Logs, in general, should never be seen by the user. I'm referring more to development and run-time logs. Things like the httpd log. Of course, we may be talking around each other due to semantic differences.

      Sometimes, when I'm writing up logging capability, I'll have certain messages go to one log, which would be the error log. I'll also have more detailed information go to another log. Then, I can read a small log to find that a problem occurred. Using timestamps, I can find out where in the other log the error is, then find out what occurred.

      *shrugs* Different folks, different strokes. Whatever works.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
      my $.02

      Actually I prefer:

      Log it all and let grep sort it out ;)

      Seriously I find the more info I log the better (or faster) the troubleshooting is. Tools like grep and sort are there for that reason, so is cheap disk space. As dragonchild points out log files are for admins and programmers not users.

      grep
      grep> grep clue /home/users/*
[reply]
•Re: Error-checking and logging
by merlyn (Sage) on Feb 26, 2002 at 16:01 UTC
    Modules. Just cause merlyn wrote it doesn't mean it works. He's human, too, you know.
    Believe me, I'm very well aware of my humanity, as are my close real-life friends. Only a human would whine this much about not being able to find a decent mate. {grin}

    -- Randal L. Schwartz, Perl hacker

[reply]
      I can't believe it, Randal disproved by a one-liner! 
      perl -e 'print "That'\''s nothing!  Try finding a female computer!\n" 
+while 1'

      [download]
      :-)
[reply]
[d/l]

        The Star Trek (TNG, and possibly VOY) ship's computer is female, at least if voice is any indication...

[reply]
Re: Error-checking and logging
by scain (Curate) on Feb 26, 2002 at 20:26 UTC
    I just wanted to add to your list of untrusted sources: data retrieved from a database via DBI. Just because that database is in the control of your company and possibly even your group does not guarantee that it is all cosher. Make sure that what you thought you where querying for is what you got.
[reply]

Back to Meditations