Fail early. Fail hard. Be paranoid

There are some things that you’re never really taught when you start building software, but just kinda pick up through repeated application of pain. One of my earliest lessons (and one I occasionally forget) is the subject of this post – code like the world is out to get you. More academically, this is called defensive programming or something boring like that.

In practice, this relates to stuff like:

• Talking to something over a socket? DB connection, IPC or HTTP connection? Assume it could go down at any point, and think about what it should do when it does go down.
• Assume that all contracts will be broken. Constructor parameters, method parameters, object types, the whole nine yards

Lets look at some code! Imagine you’ve got a constructor that expects a hash of params. Some of them might be required, others not. This could be a naive way of doing it:

See the problem? The constructor assumes that the hash it’s given is complete and that it contains all it needs. When you dereference a hash key in ruby the regular way, it will return nil if there’s no such key. So the constructor continues executing until it hits the last line, when we try to invoke a method on a nil object, getting an error. This problem isn’t unique to hashes – we can never trust that parameters passed to a constructor are correct or complete.

Here’s a better way to do it:

Here we use Ruby’s awesome Hash#fetch semantics to query the params hash for the key we need. If it exists, we grab its value the same way as before. But if it doesn’t, the provided block is invoked. In our case, since all the parameters are mandatory, we raise an Error and halt execution. If one or more of the params were optional and we knew how to default, we could just as easily return something from the block to which the instance variable is then set.

In your own projects you’ll want to tune your paranoia to how strict your contracts need to be, but in general its a great practice to adopt.