Posted by: sourceoffailure | June 6, 2008

Defensive Programming

One of the things that I am starting to recognize as both a programmer and QA is the lack of enforcement of defensive programming strategies. I recall in one class learning about how to crash programs, and the first thing I thought of was putting in a null. If you’re making your code available to others, such as an API or a class, you have to put a shield on your box. It saves headaches and blame, then the bad code can be made obvious, and that it was certainly not yours.

Programs should always expect to be given a null. Just throw the blasted exception. It’s good practice, and it can be done before the “real” code, so there’s no need to say it makes the code ugly, or that something has to be imported (it’s part of java.lang). It’s the literal equivalent of a precondition in a math proof (and everyone knows how much I hate math proofs), or jokingly, the null set is a subset of every set.

Another defensive practice that goes unnoticed is not enough arguments in some random system call with arguments (for the Windows folks that are lost, think of trying to run a DOS program with some extra information in it that the program expects). I recently crashed a program at multiple points just for this simple fact. If a program expects x arguments, then just return an exception automatically if those conditions aren’t met.

To extend the saga of this shoddy program, we expect that the user is a sys admin who can handle a stacktrace…

That’s something I disagree with because I feel:

  1. It is ugly.
  2. It is preventable.

Also, there was a bug that I found in the program that allowed the sys admin to delete the “All” project in DrProject. What if a malicious hacker got through all the firewalls and defense mechanisms? Or a sys admin mistypes? Or a less-informed user does not want the all project because he (or she) considers it a hindrance?

Quite the -little- failure.

But what is the source of failure? In this summer, in this blog, arguments will be proposed that deal with all the little gaffs in computer science. To be honest, I chose the name “Source of Failure” for my blog on a whim, and admittedly I based it on the “Worse than Failure” blog, but this one has meaning that is unknown, even to me. Its scope is beyond the scope of the “Worse Than Failure” blog; there’s a broader perspective means. This summer, I will try to answer both what “Source of Failure” means, and what we can do to prevent it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: