Defensive Development - Fail Fast or Go Home

Defensive Development is a programming practice that is frequently misunderstood, but is nevertheless a critical practice to follow when working in many environments. I have seen articles written that argue that defensive development simply causes nonsensical null checks to be written, and as a result of seeing people writing bad code defensively, argues that no one should practice defensive development. There are other articles that, like many things in software development, argue that you should always use defensive development for everything.

While I am a propronent of defensive development, like most things, somewhere in the middle of the spectrum is where I would suggest developers fall. What this means for languages like PHP and JavaScript is that when you are writing a function that accepts arguments, you should always check to make sure they are in an acceptible state before acting upon them. For example, if you need to access a member of an array or object, first, make sure that the variable is of the proper type, and that the member of the object exists before trying to access the value of the member. Failure to do so may cause errors that prevent users from interacting with your site, or in the case of PHP errors in a framework like Magento, they may be left staring at a blank white screen.

Once you determine that the parameter passed to your function is not of the correct type, you should immediately signal a failure condition for your site/application to handle the failure in a user-friendly manner. The idea is to figure out that a failue condition exists as quickly as possible and then ensure that you can properly respond to it.

In addition to checking that parameters to functions are valid, you should also check the response values from outside functions that are called to ensure that you get sane return values.

While checking all of these variables and others have sane values before using them may seem like overkill, frequently in PHP and JavaScript errors that can be found with these techniques would present a bad user experience. Properly handling these situations makes the application to better serve the user experience and inform the user of what is happening so that it can be corrected and an ideal resolution can be reached.

Related Posts

Apr 17, 2014
2 minutes

MySQL Deadlocks with Magento

One of the things that Magento, and specifically the Zend Framework provide developers is the ability to not have to think about database details as it should just handle all that for you. When it becomes obvious that there is a problem somehow with the production database getting some sort of SQL errors, its time for the developers to start caring about the implementation and architecture details of the database.

May 23, 2014
2 minutes

Avoid SiteCatalyst's useForcedLinkTracking and target="_blank"

All sites rely upon some third party analytics software to track at the very least the number of visitors to a site. Many sites use Google Analytics, which provide much more information that just the number of visitors. Another option that some of the bigger sites use is Adobe Analytics, aka SiteCatalyst to enable more custom tracking options that are not evident through the Google Analytics interface.

One feature of SiteCatalyst is that it allows you to set an option useForcedLinkTracking that will track every link on your site for clicks whether or not you have setup custom tracking for the links or not. Effectively what the code does is create a JavaScript event handler to intercept all click events on the <a href="http://url.com">Link</a> hyperlinks. Once they are intercepted, SiteCatalyst sends its tracking information to its servers and then procedes to attempt to make sure that the link functions properly. Unfortunately, in some versions of the SiteCatalyst code, it attempts to create a synthetic click event that works in many cases. However, if you are using Safari with the popup blocker turned on, and a target="_blank" in the hyperlink, then it will trigger the popup blocker, which simply ignores the click, and the user sees nothing happen at all. In order to fix it, hopefully the latest version of the SiteCatalyst code will handle it, turn off useForcedLinkTracking, or, as the very last resort, convert the <a /> links to another type of element and use JavaScript to open the new window manually when listening for the click event on the new element. It seems this works all the time, but it will prevent SiteCatalyst from tracking those clicks.

Mar 30, 2014
2 minutes

Login Problems with Magento and Varnish

When you have a Magento website configured to use Varnish as a caching frontend, there are certain scenarios where you may have some problems logging-in to the frontend of the website. It poses some unique problems that are not frequently seen on a typical website. This issue typically manifests itself to the end user by visiting the login page, entering the correct credential, submitting the form, and then the page reloads the login page again instead of redirecting to the My Account page or whatever page is specified in the configuration.