{"id":1423,"date":"2010-09-23T23:09:19","date_gmt":"2010-09-24T03:09:19","guid":{"rendered":"http:\/\/www.red-sweater.com\/blog\/?p=1423"},"modified":"2010-09-23T23:50:29","modified_gmt":"2010-09-24T03:50:29","slug":"dont-coddle-your-code","status":"publish","type":"post","link":"https:\/\/redsweater.com\/blog\/1423\/dont-coddle-your-code","title":{"rendered":"Don’t Coddle Your Code"},"content":{"rendered":"

Jeff LaMarche presents a rundown<\/a> on whether Objective-C dealloc implementations should bother nil’ing out an instance variable after releasing it.<\/p>\n

LaMarche offers a fairly balanced presentation of the two sides, but in my opinion he gives too much credibility to the argument that nil’ing is a good idea. He essentially embraces the argument that nil’ing the variables in production code is wise, because it might mask crashing bugs that would obviously vex the user:<\/p>\n

Generally speaking, this is only going to happen if you’ve got a bug elsewhere in your code, but let’s face it, you may very well. Anyone who codes on the assumption that all of their code is perfect is begging for a smackdown.<\/p><\/blockquote>\n

And speaking specifically about the approach I prefer, leaving the instance variable alone and not bothering to nil it out:<\/p>\n

On the other hand, that approach is really, really bad in a shipping application because you really don’t want to crash on your users if you can avoid it.<\/p><\/blockquote>\n

I disagree with the assertion that avoiding crashes at all costs in shipping code is the right priority. The biggest disservice you can do to your users is to allow them to run code that has unpredictable behavior. The whole point of programming is to make computers accomplish tasks in predictable ways. Sure, we all make mistakes as programmers, but giving in to the chaos and putting up safety nets “just in case” is not the right approach, especially considering it has unwanted consequences.<\/p>\n

Consider that by masking the crash from occurring in the wild, you may be putting off detection of and resolution of the underlying bug indefinitely. But if your application has a crash reporter, or if you take advantage of Apple’s iOS crash reports, you will learn quickly that there are issues needing to be resolved.<\/p>\n

It is reasonable to take steps that mask mysterious crashes, but this should only be done after you know there are actually crashes to prevent. Masking the symptoms in a blanket manner is akin to cutting half the phone lines in the neighborhood and celebrating the reduced number of 911 calls.<\/p>\n

It’s also worth noting that LaMarche’s defense of nil’ing out instance variables hinges on the presumption that messaging nil is safe. True, messaging nil will not cause a crash. But is that safe? Not if it changes the behavior of your code in unpredictable ways. Consider this incredibly contrived Cocoa-based nuclear arms controller:<\/p>\n

\nif ([mDiplomat didReturnGestureOfPeace] == NO)\n{\n \t[[NuclearWarehouse nuclearMissile] launch];\n}\n<\/pre>\n<\/p>\n
By LaMarche’s reasoning, it’s a good idea to nil out the mDiplomat variable on release, so that it won’t crash when you message it. But in this case, messaging nil for a BOOL result causes a logical flaw in the program, with obviously dire consequences. If the instance variable were not set to nil, it would probably crash before the launch message could ever be sent.<\/p>\n
We should aim to comprehend what our software actually does. Deliberately decreasing the symptoms of problematic code won’t lead us any closer to that understanding. Ship the best code you have to your customers, and if it crashes, try to fix the root cause of the crash as quickly as possible. Don’t get in the habit of writing “hope this fixes it” code, and by all means don’t adopt that philosophy as a boilerplate coding habit.<\/p>\n","protected":false},"excerpt":{"rendered":"
Jeff LaMarche presents a rundown on whether Objective-C dealloc implementations should bother nil’ing out an instance variable after releasing it. LaMarche offers a fairly balanced presentation of the two sides, but in my opinion he gives too much credibility to the argument that nil’ing is a good idea. He essentially embraces the argument that nil’ing […]<\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,15,50],"tags":[],"class_list":["post-1423","post","type-post","status-publish","format-standard","hentry","category-cocoa","category-programming","category-rant"],"_links":{"self":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/1423","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/comments?post=1423"}],"version-history":[{"count":21,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/1423\/revisions"}],"predecessor-version":[{"id":1444,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/posts\/1423\/revisions\/1444"}],"wp:attachment":[{"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/media?parent=1423"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/categories?post=1423"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redsweater.com\/blog\/wp-json\/wp\/v2\/tags?post=1423"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}