Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Replace `assertions` by raising Errors #622
I was reading through python exercise and It seems to me that the Defensive Programing session is introducing assertions, where I believe Type- or ValueErrors should be raised instead:
For the post-checks it probably doesnt hurt to raise
Regarding the test-driven development: I have done this in my own code and this is at least a few hours on its own. May it be more useful to introduce the
referenced this issue
Feb 14, 2019
This is definitely an interesting discussion and I fully agree with you that introducing
Some time ago, I'd be strongly against adding
Note: this comment is in need to satisfy the Carpentries Checkout Procedure Part 1.
I believe that the section on "Defensive Programming" is off target. Defensive programming should be viewed as making your software resilent to errors that result from incorrect data provided to the software (whether direct from a user or otherwise), not necessarily the reliability of the software to respond correctly to a user based on embedded logic; this later concept is perhap more the domain of test-driven development.
This section currently emphasizes the use of assertions, which does not improve resiliency - asserts, in general, result in catastrophic exceptions (i.e., the program aborts with a stack trace due to an incompatible state between what is expected and what is actually occurring) and are generally used in test driven development to indicate whether the software is performing as stated in a requirement (in other words, does the software perform to a given specifcation). The use of "assert" in production Python code is generally used for debugging purposes, thus the compile optimization flag indicated by @skuschel to ignore such code while during production operation. I agree with @skuschel that a better approach to this section would be to replace "assertions" with "raise" (exception), along with a "try/catch" scenario, which is better suited toward defensive programming. With a "try/except" pattern, the software can "catch" and respond to erroneous data without resorting to immediate termination (or if it does, then it can provide more meaninful and human consumbable information to correct the situation). This approach is also a more natural progression from the prior section on "Errors and Exceptions".
In summary, I don't believe that "test driven development" and "defensive programming" should be conflated as one and the same. As such, this section could be rewritten to represent "defensive programming" using Python's "try/except"; alternatively, it could be rewritten to address the practice of "test driven development", which may be beyond the scope of the Carpentries lessons.
referenced this issue
May 3, 2019
I think this has merit. Asserts really make more sense as a part of testing. Since we currently don’t cover testing in that much depth but do cover almost by definition programs with
I see exceptions as a good target as programmers need to familiar with them anyway...
It is also fairly easy to retain the defensive programming theme with exceptions while not commiting students to obscure errors in the future.