How to assert for fun and profit (2022)

Asserts are essentially checked comments and an automated test is not a replacement for comments.

I've done things like the following many times:

    if (x != 5) {
        ... 40 lines here ...
    } else {
        assert(x == 5);
        ... more lines ...
    }

The main purpose of the assert is to remind the reader that x == 5. There was a time where I would use a regular comment for a reminder like this, but since it's something the computer can check, I mine as well turn my regular comment into a checked comment.

I don't see this as either or. Good quality asserts can be very effective when managing objects with complex state transitions

For me assertions are for invariants. The code has no expectation of successful execution

I also like (borrowing from testing) the idea of expects, where we can hope that the object is in a specific state, but have an explicit compensation path for when it isn't, perhaps objects that need to be migrated to a new schema etc.

Unit tests are complementary to assertions, they don't supersede them.

I feel that assertions are the first line of defense against programming judgement errors/omissions and are much easier to write in the given context than unit tests.

Inline assertions do have one big advantage over tests: context. They're right there in the very place where the condition must hold. For that reason, I have long thought of assertions as 'comments with teeth'. Also, inline assertions can be enabled any time, not just when running unit tests.

Of course in theory that last bit shouldn't make any difference, but then I'm sure you've already heard the old joke about the difference between theory and practice..

Seems to me that asserts are a force multiplier on tests. If you have a bunch of asserts, every test case you write is extra valuable -- you aren't just verifying correct input/output behavior, you're also verifying that all asserts held.

In the extreme case, I can imagine ditching all your small-scale unit tests for a combination of asserts and end-to-end integration tests.

In C and C++ at least, asserts are also hints for the static analyzer (for instance that a pointer isn't expected to be null).

It's better to do both, asserts and tests are not mutually exclusive, they complement each other.

> effort writing assertions in production code

Presumably the assert is used because it doesn't consume resources (ie effort) to write. Testing takes a lot of effort.

Exactly.

Assertions are for programmers and their internal work. Exceptions for the rest, mainly the dynamic, user controlled inputs and their derivatives.

Re: data from another of your own systems. If there’s an interface between them that suggests you probably want those systems decoupled. Maybe in the future you replace one system with another you don’t control - ideally it would be nice not to have to make code changes because of that.

Re: asserting on user input. If you assert only then what happens on bad inputs when asserts are switched off in prod? Seems like an outcome you’d like to control at the time rather than allow to propagate (by writing bad data to a db and only being discovered months later, for example).

This would probably be used in places where, if the “x” in assert(x) doesn’t hold, then the program could do more harm than good. You’ll generally try to handle situations that are recoverable without blowing up stuff like this, but in some software and some situations you want it to blow up fast rather than destroy data or whatever. I program in Python more, which has slightly different assert behavior so it’s considered more of a code smell in that language, but it seems like Java programmers use it more because it can be turned off easily when not wanted.

The user obviously doesn't want the program to crash, but they don't want to encounter any bugs. If an assertion fails, it means they already encountered a bug and the program is about to wander through a minefield of unspecified behavior, which could be much worse than simply stopping.

Asserts are not an alternative to validating user input or input data in general (e.g. data loaded from files or received over the network).

If wrong input triggers an assert, that means that the input validation is incomplete (and in that case the assert may prevent further much worse damage, and also provide important information to the programmer who's going to fix that bug).

Basically, asserts should never trigger if the user "does something wrong".

It's very controversial, but I like Go's approach of treating errors as return values - because that is ultimately what they are.

You can have your language hide exceptions from the control flow if you wish, but they are still things that result from function calls that you should deal with. Why not make them front and center?

You should use asserts or throw errors to prevent misuse of a procedure by the caller. Ideally, you could model these constraints at the type level. You can think of pre-conditions as a sort of pseudo-dependent typing.

Consider the following pseudocode:

    // Idris
    binarySearch : SortedList a -> a -> Maybe Nat
    binarySearch = ?implementation

    // Java
    int binarySearch(List<T> elems, T elem) {
        assert isSorted(elems);
        throw new NotImplemented();
    }

(The generic type parameter should also implement Comparable or similar, but I digress).

In this case, it would be nonsensical to pass an unsorted list to either procedure, so we prevent it - in Idris' case by using dependent typing; in Java's case by using assertions.

To contrast, consider the following:

    // Idris
    readLines : Path -> IO (Either FileError (List String))
    readLines = ?implementation

Here, the FileError represents a number of things that could go wrong: no file existing at the given path, lack of permissions, running out of memory during read and so on. However, this is not misuse of the procedure - these are all expected deviations from the happy path, and hence we model that in the type definition.

(I've omitted a corresponding Java example, as following a similar style would be terribly non-idiomatic. Java prefers throwing and catching exceptions to manage non-happy paths)

Note that we can't constrain the Path parameter to only resolve to files that exist. Doing so would require knowledge of the current filesystem state, e.g. the type signature would be something like the following:

    readLines : (fs : FileSystem) -> (p : Path) -> fileExists fs p -> IO (Either FileError (List String))
    readLines = ?implementation

To summarize, use preconditions, assertions or type-level constraints to prevent misuse of procedures. Return errors (using sum types, for example) when it is known and expected that the result of a procedure can deviate from the happy path. You may refrain from modeling conditions at the type level, even if possible in principle, as it may be prohibitively complex.

>if you are throwing an error in most of the languages your caller function will not get an idea that this function can throw an error

Is this true any more? I feel like most languages, relative to popularity, have compiler-enforced thrown error handling.

That’s the thinking behind Either (in functional programming, but not only).

TBH, I don’t understand how the absence of checked exceptions or Either in most languages is tolerated!

and from that - all the reasons to use it. A properly placed assertion statement is the only thing that stays between you and a misery of weeks-long debugging sessions.