Is `print statements` a defensive programming technique?

Question

We had an exam and the question paper asked which of the following is not a defensive programming technique. I've answered it as print statement, that a print statement is not a defensive programming technique. I went back to school after 6 years of working as a programmer and I've not used print statements anywhere in the production level code(I've used loggers at all levels, but the print statements here means Sys-out statements) and the professor argues that he uses print statements in the code and hence it is a defensive programming technique(and the correct answer is encrypted object code, and yeah I agree that is not a programming technique at all and hence not a defensive programming technique, but so is/are print statement/s). I tried to show code bases of some open source projects on GitHub, but he wouldn't budge.

He is not open to discussion and hence I'm posting it here. He showed me an image from a book, I'm arguing that the defensive programming technique that is referred to in the book actually refers to if conditional and not to print statements. Need a tie-breaker on this one as well.

Answer 1

I would not call printf defensive programming.

Diagnostic programming for sure.

But defensive programming has to do something; validate preconditions, sanitize inputs, etc. printf logging can let you know what exploded and why, but it cant prevent the explosion from happening. Defensive programming can.

Answer 2

"Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances" https://en.wikipedia.org/wiki/Defensive_programming

I would argue that print statements -- whether alone or accompanied by any level of conditionals etc. do not accomplish the goals of defensive programming. The intent of defensive programming is to ensure that the code is used as it was intended by the writer. Even if they alert the user to the fact that something is going wrong, they do not enforce a behavior in the code. Inputs that are unexpected could be run through just as they were before. Neither of the two options accomplish this goal.

As a note for others, the book mentioned by the poster is "Introduction to programming concepts with case studies in python" and can be accessed on google books. The section highlighted is the only occurrence of the phrase and occurs in the chapter on debugging. The author does not provide a definition for the term, which is why I included the above definition and why I am inclined to agree that the author could have been referring to the conditionals themselves and used the prints solely in brevity to illustrate his point and not as the key take away. It seems a little out of context as an explanation for the definition of defensive programming.

All of this being said, in the end the result of an exam is not really something that can be dealt with in this manner. If you are looking for more information to have a more informed conversation than that's what you will find here. Advice for your particular situation is probably a little out of scope.

Answer 3

In addition to the points already mentionend by whatisname and Zach M., I'd like to point out that even the book is wrong (at least in calling this "self-explanatory"), as the defensive guards do not actually prevent further execution.

Doing a simple

if n == 0: print "n should not be 0"
x = y / n

is just the same as saying "hey, the program will crash in the next line".

Real guard conditions would break execution early, by returning an error state from the method, throwing an exception, or whatever means your programming environment of choice offers.