While I was reading the book Code Complete: A Practical Handbook of Software Construction, Second Edition, I learned what defensive programming is and more specifically, how many actions programmers can choose to take when dealing with unexpected or bad inputs.
What Is Defensive Programming?
According to the Code Complete book,
In defensive programming, the main idea is that if a routine is passed bad data, it won’t be hurt, even if the bad data is another routine’s fault. More generally, it’s the recognition that programs will have problems and modifications, and that a smart programmer will develop code accordingly. - Code Complete, Chapter 8: Defensive Programming
I, thus understand the concept of defensive programming as 'Correctively dealing with unexpected(which mostly means 'bad') data so that letting the program still functional as expected.' Let me know if you find or think there is something wrong with this way of understanding..
Assertion
There are many ways of defensive programming discussed in the book. One of the ways of defensive programming is called assertion.
The code below is the example of the assertions discussed in Java from this book:
This assertion checks if denominator is 0; if it's 0, then it should be highlighted and the programmer need to know that, so it will display a message saying
denominator is unexpectedly equal to 0.
Defensive Programming for Having Safety Net and Program Efficiently
The example above was just one of the many examples of ways of defensive programming in the book. Defensive programming allows programmers to have a simple, but useful safety net from crashing the program or unexpected errors or bugs that may cause the development slow, which definitely will be crucial and serious if you are doing that for living, certainly. Thus, defensive programming is an option that all programmers have, to protect themselves and program efficiently.
Love the formatting :-) Of course remember that lots of assertions can adversely effect run-time performance, but then one certainly shouldn't prematurely optimize for performance. Still my personal preference is to wrap code in thorough tests as a way to defensively check that everything is as it seems. This has the advantage over assertions in the body of the code since the tests are a separate code base, don't impact run-time performance and provide a form of documentation about how the code should be used.
ReplyDeleteRegarding the suggestions from code complete I would focus on error handling in general rather than specifically assertions myself. Having the run time code communicate effectively with the end user about problems it encounters seems the critical thing. If an assertion failing produces comprehensible output, e.g. the "denominator is unexpectedly zero" as in your above example, then it's just a type of general error handling. Part of the difference here is one of terminology from the C++ world to the Java world to the Ruby world. Whether you are throwing an exception, failing an assertion or throwing an error the key thing is the nature of the message, and how it will ultimately be presented to some consumer ...
Sam,
DeleteThank you very much for your comment! :)
"Having the run time code communicate effectively with the end user about problems it encounters seems the critical thing." - I strongly agree with your opinion .. will concentrate more while reading and definitely will try to write more quality, worth reading blog! :)
Great Post:)
ReplyDeleteyour post helps me better understanding because I was confused about contents of difensive programmer, such as exception and assertion. I am still trying to understand it. Any way, I understand why difensive programming is important for making for Safety Net and Program Efficiently. Thanks!