swcarpentry/curriculum-advisors

[python-novice-inflammation] Replacing assertions with exceptions for defensive programming

Closed this issue · 2 comments

See swcarpentry/python-novice-inflammation#979.

The lesson maintainers believe that this change does not require CAC approval, but may benefit from consultation.

While the maintainers seem to want this change, I would be interested in discussing the trade-off between the beginner-friendliness of assert and the "best practice"-ness of raise.

At our 2022-Q4 meeting, the SWC CAC discussed and voted on this topic. I'm now closing this issue with a brief summary of our committee's consensus.

First, there is a question about whether a decision one way or the other requires a CAC opinion. We did not discuss this "meta-question" explicitly, and operated under the assumption that our discussion would be purely advisory and not binding for @swcarpentry/python-novice-inflammation-maintainers. However, since swcarpentry/python-novice-inflammation#981 has not yet been merged, it seems reasonable to think that maintainers will carefully consider our discussion before merging these changes.

Likewise, this opinion will be relevant to @swcarpentry/python-novice-gapminder-maintainers if they are considering adding defensive programming content to that lesson.

The actual question we considered is whether the Defensive Programming episode in swcarpentry/python-novice-inflammation should be changed to replace use of python assert statements with raise SomeError. This is not, therefore, 1-to-1 with @DamienIrving's PR, which keeps some discussion of the former while adding and prioritizing the latter.

Ultimately, the committee vote did not result in a clear opinion.

On the question of replacing assertions with explicit exceptions, we voted 2 in favor, 2 against, and 2 abstentions.

Despite this split vote, there was general consensus about the pros and cons of making this change. I'll now try to summarize those. Other committee members may also comment on this thread to clarify/expand on their thoughts.

Pros:

  • Exceptions are a more general feature in Python that learners should eventually know about.
  • Exceptions can reasonably be used to check programmer assumptions, just like assertions, but are also useful for enforcing invariants for other users. This is a subtle distinction—also related to the fact that assertions may sometimes be optimized out during code compilation—and by using exceptions throughout (instead of a mix of both) we might reduce cognitive overhead for learners.
  • Exceptions, especially custom ones, are best-practices for being explicit and informative about how inputs have failed to conform to assumptions.
  • try/except functionality is also (eventually) valuable for python learners, and requires an understanding of exceptions, not assertions.

Cons:

  • Assertions can be taught without first teaching conditionals. Exceptions, on the other hand, have this pre-requisite, and introduce some cognitive overhead when teaching defensive programming. As a result, switching to exceptions would also reduce flexibility for instructors in how they order and customize the episodes.
  • Related: assertions can be taught more quickly and therefore reduce the total time necessary for the lesson. This lesson is already challenging (or infeasible) in a one-day, two-session format, and adding material/time requires that other content be removed.

While we have formed our committee opinion, and I'm closing this issue, further discussion can take place here or on other existing PRs/issues.