I love assert

[Steven D'Aprano]

Marko Rauhamaa wrote:

> Asserts are not about notification, checking or optimization. They are
> about communicating what's going on in the programmer's mind. They are
> comments.

Assertions can be used for *all of these things*.

Assertions can be used for:

- checking internal program logic;
- testing pre- and post-conditions;
- testing program invariants;
- comments which are verified at runtime;



> So why use asserts instead of comments?

Not all comments can be replaced with an assertion, but some can:

# once we reach here, mylist has at least two items

is better turned into an assert:

assert len(mylist) >= 2


To someone who is fluent in Python, the assertion is as easy to read and
understandable as the English comment. And it has the added benefit that
the interpreter will verify that the comment is correct at runtime.
Verifying comments is important, since programmers are notorious for
ignoring comments and failing to update them:

http://import-that.dreamwidth.org/956.html

Why would you choose a comment rather than an assertion? If the code is
performance critical, and the extra cost of the assertion is significant,
and you cannot reasonably run the code using -O to disable it, then a
comment might be better.


> Asserts *could* help in fixing bugs:
> 
>   1. An assertion failure immediately, unambiguously, declares even to
>      customer service representatives that this is a terrible bug and
>      should be brought to R&D's attention instead of hazing the poor
>      customer with standard questions ("have you updated?", "have you
>      rebooted?").

If only that were the case :-(


>   2. An assertion failure probably gives the developer an very good clue
>      as to what has gone wrong. There is a good chance of quickly
>      finding an accurate analysis and fix to the bug.

In general, it is desirable to have any eventual exception occur as soon as
possible to the ultimate cause of the exception. Assertions can aid in
that. Languages such as Eiffel provide a rich and powerful set of different
assertions, including:

    require
    ensure
    check
    debug
    invariant

The Eiffel manual is explicit about the correct use of assertions:

    It should be clear from the preceding discussion that contracts 
    are not a mechanism to test for special conditions, for example
    erroneous user input. For that purpose, the usual control 
    structures ( if deposit_sum > 0 then ...) are available, 
    complemented in applicable cases by the exception handling 
    mechanism reviewed next. An assertion is instead a correctness
    condition governing the relationship between two software modules
    (not a software module and a human, or a software module and an 
    external device). If sum is negative on entry to deposit, 
    violating the precondition, the culprit is some other software 
    element, whose author was not careful enough to observe the terms 
    of the deal. Bluntly:

    Rule -- Assertion Violation: A run-time assertion violation is 
    the manifestation of a bug.

    [...]

    That violations indicate bugs explains why it is legitimate to 
    enable or disable assertion monitoring through mere compilation 
    options: for a correct system -- one without bugs -- assertions 
    will always hold, so the compilation option makes no difference 
    to the semantics of the system.


https://docs.eiffel.com/book/method/et-design-contract-tm-assertions-and-exceptions



-- 
Steven