Talk:Defensive programming

From Wikipedia, the free encyclopedia

copied from article, "Please expand this article. These random notes should be changed to a more coherent article." Badanedwa 22:52, May 1, 2004 (UTC)

[edit] humm

This article its somewhat obsolete-ish, and feel too unix oriented. Maybe sould be edited to leverage this unix oriented style, then adding nowdays-sche stuff. Ok, maybe I am wrong. What other people think about the quality of this article? --Tei 15:09, 19 July 2005 (UTC)

I agree that this article needs cleaned up. - brenneman^(t)(c) 05:24, 6 August 2005 (UTC)

[edit] Bug Free

How does Defensive Programming differ from Standards of Good Software Development? Now I have been a computer programmer for over 40 years and fully agree that there is an enormous volume of crud out there, as we can see with the volume of patches coming from major software suppliers to fix problems that should never have been there in the first place, but most everything I am seeing in this article is talking about standards that most every programmer should adhere to, with variations on how to implement them by actual computer language, but few do. User:AlMac|^(talk) 18:11, 18 January 2006 (UTC)

[edit] I do NOT adhere to these rules

I see defensive programming a method that can be used when it is reasonable to both expect and possible to counteract intentional and accidental misuse of the code. The problem is that it is easy to hide the problem without alerting anyone about it. I it a design choice among others. Another approach if defensive programming is not used is to let the application crash, or in some other less drastic way make the call invalid. In other words enforce the correct use of the piece of software in question.

The idea that defensive programming is good programming is wrong, but one way of designing the code. The question is how to define the term properly. —Preceding unsigned comment added by 137.61.234.225 (talk • contribs)

You didn't specify the programming language you use. In languages where an exception would be thrown and caught, and the traceback would be logged - sure. But in lower-level languages, most notably C, ignoring error returns will often lead to hard-to-debug situations much later in code, having possibly overwritten stack in some situations. Of course it depends on how well thought-out your error handling policy is; I personally consider it easier to drop log a message and attempt to abort the current operation as gracefully as is realistic. I realize the error handling codepaths can much more likely have bugs as they're not tested very often, but it's not a much worse situation. -- intgr 17:14, 3 October 2006 (UTC)