Error Handling (or Lack Thereof ...)

We've all been told at some point how important it is to check for errors.  We all nod our understanding and proceed to do things the way we've always done them.  We've all done this (and we nod again).

I'm probably more adamant than most about building good error checking into a program at the very beginning.  With 40 years of programming (and debugging) experience, I've been burned plenty by poor (or no) error checking.  But I still need to get burned occasionally to remind me.

I write a lot of scripts on my Linux server to automate things.  I'm a big proponent of Cron jobs, At jobs, and Procmail for handling the thousands of little activities that need to be performed on a daily basis.  I try to make it a point in my script writing to check for errors and include at least a stub to let me know I've run into a ditch or hit a speed bump.  But, sometimes I'm in a hurry or it's very late (after 3 AM) and I think: "I'll worry about this later."  Hah!  Right!

While using my Nexus 7 last week I saw the beginning of a YouTube video that I thought I'd like to watch on my server's 22" display, so I shared the video to my server Email address.  I have a rule on Procmail that recognizes YouTube share notices and automatically captures the referenced video and queues it up for viewing.  I saw my script's notice that a video had been captured, but the video was nowhere to be seen.  Oh, must be a bug.

So, I manually issued the command the script issued, which was to run a third-party Python program.  Aha!  A string of traceback messages indicating a problem with capturing the video.  But why didn't the script do something with those messages?  Well, it did, but ...

The normal output to stdout from the Python program is a single line giving the video's title.  My script took stdout and wrote it to a file of captured videos.  So, when I really dug into the problem, I found the error messages, but not where they would have been helpful.

So, the solution here was to capture the output from stdout and count the number of lines.  If just one line, it's a good capture and the line is the video's title.  If more than one line, assume it's a traceback of some sort and report an error via Email, including the traceback text, so I get notified there was a problem and have the first level error information in front of me.

While the problem description and solution appears pretty simple, as is the nature of after-action reports, taking the time to investigate, debug, and improve the script took several hours over the period of a few days.  This was an isolated event related to a specific video, so I wasn't shut down or otherwise impeded from normal usage of my system.

So, what's my point here?

Whether it's a simple-minded script of a few dozen lines or a complex program of hundreds or thousands of lines, you need to think about error handling beyond just simply checking return codes, which you should ALWAYS do.  If you always expect one line of text, check the line count and report zero or multiple lines returned.  If you expect a certain string to be part of the line of text, check for its presence and report if not found.  When testing, try to simulate errors wherever possible so you know what gets returned and are prepared to handle it.  Oh, and even when you're checking those well documented return codes, do something about the undocumented ones, also.

Okay, I see lots of nodding heads.  Just one more piece of advice:  buy some burn ointment.  We'll all need it sometime.  I just prefer to buy mine one small tube at a time.

Hello!

The term software guy seems an apt description here in upstate New York.  Our plow guy takes care of pushing snow around.  Our stone guy provides the gravel that keeps our car from sinking into the mud.  So I’m a software guy.  And that feels right.

I’ve been programming computers since September 1968.  It started as a hobby, something to do with my best friend.  I was hooked almost immediately.  Even when I didn’t have access to a computer, I was writing code, initially in BASIC, then progressing through machine language, assembler, and Fortran before I was out of high school.  And yes, I had glasses and a pocket protector.

College was another quantum leap.  I was introduced to the IBM 360/65, then the Data General Nova series of minicomputers, then Intel’s newly introduced 4004 and 8008.  And I added a slide rule holster to my wardrobe.

College graduation was a long time ago.  At times I feel a bit like Forrest Gump, being in the right place at the right time to watch the computer business change.  Computers have gone from being the domain of the techno-wizards to being on every office desk to being in nearly everyone’s pockets.  Programming is still a bit of a wizard’s job, but even that is changing with new tools being introduced every day to make control of our ubiquitous computers easier.

So why am I writing this blog?  Good question.  I’m hoping that the process of writing will help me answer that question for myself.  In the mean time, I’ll write about what I’ve done for more than 40 years and feel I know best — software.  My current favorite software topics are Linux, C/C++, and embedded systems, so I’ll write about those.  My biggest hot button is error handling (or lack thereof), so I’ll write about that, too.

Welcome to my confessions.