As I’m sure is true with many of you reading this, I’m a busy guy. My days seem shorter than they used to be, though I’m pretty sure the Earth is spinning about the same speed it was ten years ago!
Nevertheless, when it comes down to scripting and programming, I try to take my time. When I’m in the process of writing code, especially when that particular bit of code may involve external processing (say reading from a URI), I like to think out all the possible ways it could go wrong. Not only is this good programming practice for debugging purposes, but writing it in such a way allows you to present very relevant and accurate error messages to your users.
Now, let me explain why this is important.
Earlier this week I was offering help to my housing overlords with a computer problem they happen to use for their point-of-sale system. Whenever they tried to print a receipt on their printer, an error message would pop up stating “Insufficient disk space to print”.
The computer had 300GB of free disk space.
To make a long story short, the program lied. The problem was that “C:\windows\temp” had the read-only attribute turned on. The disk wasn’t full at all, but since the printer driver program couldn’t write to that path, it assumed the drive was full. We all know what “assume”-ing makes us…
One silly coding choice by a programmer burned several hours of my life away. If the programmer had simply chosen to test a few conditions before attempting to write the file, namely:
- Does the directory exist?
- What are the modes on the directory?
- Is there a file named the same as I’m about to write?
- … and so on