Defensive Programming

[[deleted user]]

Error handling is an area often left out of academic treatments of software development, but can require as much thought and create as much grief as the functional code. I am glad to see a whole chapter devoted to various options and strategies for handling errors, and their pros and cons. I especially enjoyed the discussion about exception handling in programming languages, and I agree that exceptions are often misused, mainly because they are raw facilities in need of an overarching architecture and strategy, which is often missing in projects.

The idea of barricades was new to me, and it seems like a good strategy for secure coding, where a "trust no one" mentality prevales.

[Erik]

I have not used assertions as postcondition checks, but that's a great idea. It almost seems like using nunit to make test cases.

The ancedote about the unprofessional debug messages hits home too. I had some coworkers do that, but our customers were not amused when the found the debug messages.

Aside: My computer crashed, so I'm very far behind the group in reading this book.

[Aleksander]

I liked the discussion on Debugging Aids and Defensive Programming in Production and Development code. For some reason I’ve never thought about the difference between production and development code or mode as described in this chapter. Writing debug code takes time, and it makes sense to activate or deactivate it as needed using tools that already available like preprocessor or source control. I need to research if my IDE already supports some DEBUG directives for debugging.