Possibly the wisest piece of programming advice I ever received was to program for exceptions. Any random guy with one eye and one finger can hack out a program, but our job as a software professional is to handle exceptions, and I don’t mean the try..finally kind. Rather, program for unusual events. This separates ordinary software from what we generally know as user friendly software.
When you study programming in TAFE or University you are taught to solve the problem. Most will also teach you to put in some basic data validation, such as making sure required fields are not blank. But real exception handling is more than that. You need to think of all the crazy things an end user (or the operating system, or the hardware) might throw at you and make a conscious decision on what to do.
What if a price list file arrives and is empty? or in the wrong format? or two columns have the same name? or number formats aren’t what you expect? is the file complete? how do you know?
An example we came across recently was in the Softmaker Office suite of products. Univex software will export reports to Microsoft Excel, Open Office, and Softmaker Office (amongst other text and HTML based formats). With Softmaker, if the data format for a negative currency value is not in the $-x.xx format, it will not interpret the data when you look at the file later on. The odd thing is that the software allows such a value to write out ok.
This is a great example of not handling exceptions. The programmers never contemplated that the software might be used in a location that has a different format for negative currencies. The default in MS Windows (at least here in Australia) is -$x.xx. Try putting that through Softmaker and the value is not saved out. No errors, just an invalid field value written out to disk.
So in turn, we handle the exception in our software. We make sure that whenever writing out a negative value to a Softmaker file we meet the requirements. We also tested Excel and Open Office to double check they still export ok!
If you are looking for more tips on crafting software that is easier to program, easier to test, easier to maintain, and is half-decent to boot, I recommend the book The Pragmatic Programmer. You don’t have to agree with everything the authors suggest, but you have at least got to respect their position for trying to help programmers become better professionals, much like other engineering fields.
