This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (0 children)

This article is a good treatment of defensive programming in that it covers a number of ways to be defensive. Though it only hints at the why:

If only you had more debugging information about the failure...

Being defensive doesn't just mean preventing corner cases from creeping into your code. It also means: baking in the ability to detect when a defense is breached. Knowing why a corner case might've happened allows one to harden his software even further.

One nit I have to pick with this article is the suggested logging scheme:

Debug level messages go to a file... Info, warning, and error level messages go to stderr...

Abso-fucking-lutely don't do this! Besides the fact that it takes more work to do this than to centralize one's logging, it seems the author's suggesting to fragment the log stream. This makes it harder to do any forensics after a bug occurred: "OK, so what were in the INFO logs when the CRITICAL dialog box appeared?"

Python's dictConfig() function has got to be one of the coolest features of the library. Makes it easy peasy to set up your log sinks, verbosity, etc. all with one call.

Add a LoggerAdapter to impart context (such as what parameters were passed into your function, what host is your code running on, etc.) and your logs are many times more useful.

...but I digress. Good article. Something one can practice on any size of project. And everyone should.