CppCon 2014: John Lakos "Defensive Programming Done Right, Part I"
Why Software Engineering Stack Exchange recommends it
Software Engineering Stack Exchange users link it when answering questions about asserts, preconditions, exceptions versus assertions, and class invariants in C++.
Recommended by 1 people across 1 different months, 2015 to 2016.
What it is
A CppCon 2014 talk by John Lakos on how libraries should handle precondition violations using Design-by-Contract, undefined behavior contracts, and configurable assertion levels. It argues that how much to validate, and what to do on failure, should be decided per application by the owner of main. This is Part I of a two-part talk.
What people said
Recommends D Drmmr · 2015-09 · Software Engineering Stack Exchange · on “When is it ok to assert for a pointer being non-null?”
John Lakos' presentation _Defensive programming done right_ talks about this in great detail. part 1 [this video] part 2 [LINK]
Cites ComicSansMS · 2015-01 · Software Engineering Stack Exchange · on “Throw exception or let code fail”
The fundamental question that you have to ask is: What do you want the interface for your function to be? In particular, is the condition _Materials.ContainsKey(name) a precondition of the function? If it is not a precondition, the function must provide a well-defined result for all possible vales of name . In this case, the exception thrown if name is not part of _Materials becomes part of the function's interface. That means it needs to be part of the interface documentation and if you ever decide to change that exception in the future, that will be a breaking interface change . The more interesting question is what happens if it is a precondition. In that case the precondition itself beco
Cites 5gon12eder · 2015-10 · Software Engineering Stack Exchange · on “Do you throw an argumentexception or argumentnullexception from private methods?”
I realize that while the question has no language tag, it is probably implicitly talking about “coffee languages”. But just for the sake of completeness, I'd like to mention the somewhat diverging apparent consensus in the C++ world. There are three things C++ programmers will typically be interested in: Will it have zero-overhead in optimized builds? (That is, can it be “compiled out”?) Can I use it to trap into a debugger right at the point where the error was detected? Can I use it to report problems from functions declared noexcept ? In the past, I have approached the first problem by writing code like this int factorial(const int n) { if (CHECK_ARGS) { if (n < 0) throw std::invalid_argu
Cites 5gon12eder · 2016-01 · Software Engineering Stack Exchange · on “Is possible to write too many asserts?”
Is possible to write too many asserts? Well, of course it is. [Imagine obnoxious example here.] However, applying the guidelines detailed in the following, you shouldn't have troubles pushing that limit in practice. I'm a big fan of assertions, too, and I use them according to these principles. Much of this advice is not special to assertions but only general good engineering practice applied to them. Keep the run-time and binary footprint overhead in mind Assertions are great, but if they make your program unacceptably slow, it will be either very annoying or you will turn them off sooner or later. I like to gauge the cost of an assertion relative to the cost of the function it is contained
Cites D Drmmr · 2016-02 · Software Engineering Stack Exchange · on “C++ class design with invariant”
Use the strongest guarantee that you are willing to maintain for the foreseeable future. Method 4 (template / static assert) assures that the invariant is always true in a compiled program. However, this implies that the input must be known at compile time, which is not always possible. Method 2 (assertion) and 3 (exception) can fail at run time, so they offer a weaker guarantee than method 4. The choice between an assertion and an exception depends on the audience (who will use the class), the applicable coding standard and the possible repercussions of failing to maintain the invariant. For an in-depth treatment, see John Lakos - Defensive Programming Done Right [this video] . Use an assertion