Rust's Two Kinds of 'Assert' Make for Better Code

> since you've had some bad experiences

No, I've had great experiences with assertions in code. People have paid my salary because the assertions are invalid and cause more problems than they solved. :D

> Failing an assert in production of course sucks and is costly. But what is more costly is letting the bug slip through and cause hard to diagnose bugs, program incorrectness and even (in some cases) silent address space corruption that will then manifest itself in all kinds of weird issues later on during the program run.

The direct counterpoint to this is that:

Any assertion that validates a runtime invariant can (and IMO should) be converted into a test which covers that same invariant, with coverage information proved by tooling.

This is possible unless the underlying design of the system under test is such that it prevents adequate testing, or your approach to testing is lacking. If you have those problems then asserts are a band-aid on broken practices. Moving quality checks to the left (design / compile time, not runtime) is a generally beneficial practice.

Put another way, I've seen many bugs which should have been caught cheaply early with adequate testing practice, rather than at runtime where they caused system failures. It's a rare bug that I see that that isn't the case.

Perhaps there are points where this broad recommendation doesn't apply. Safety engineering might be one of those, but the problem space of selling someone a widget over the internet rarely has that same level of need for runtime invariant testing that sending a rocket to space might.

---

On a different side of this, I do think that system level assertions (i.e. real code paths that result in actions not `debug_assert!` calls which result in crashing) can belong in systems to check that some process has reached a specific state. I prefer systems to be designed that don't (provably) crash ever.

---

A third side to this is that assertions are code too. They are a place which is rarely if ever tested (and is generally impossible to test because they cover invariants). This means that they're an unmitigatable risk to your system.

A thought experiment for you, what if LeftPad[1] (instead of being deleted) added an assertion that the total number of characters was [1]: https://en.wikipedia.org/wiki/Npm_left-pad_incident

My thinking was that this would be up to the compiler, where you’d have to specify the target CPU model for it to take advantage of the feature. Similarly, byte code VM could use this with runtime detection of the CPU properties.

This would work best in a high level language where the specific bit layout of struct types is not defined (by default). Rust is one such language, but this would also work with .NET and JVM languages.

One approach is that integers are represented as A x Pointer types could be internally represented as ordinary integers, or aligned non-null pointers on some architectures would be “0 x This could have no effect on the emitted code, but the compiler would be free to utilise the spare low bits or the non-zero value if it chose to do so. Rust does this in a few hard-coded scenarios, but a more complete type model would allow more flexibility. I.e.: it could pack the enum discriminator and the value in there if the enum has only pointer types as values.

Conversely, the high level language can use this for type checks to give better error messages.

I realize you could probably build this in lisp, but this (by default) seems to be missing the part about jumping back to where the exception was raised, instead of resuming flow control from where the restart was defined, iiuc.

Basically what you're saying is

"If you never have an accident you don't need seat belts in the car, and since we test drove the vehicle in the factory parking lot and didn't have an accident we decided not to have the seat belts".

Point being asserts are the final back stop. Your unit tests don't help you validate/test any real execution instance or function call that happens right now in production.

You're right in the sense though that if you have some functionality that is only ever called in a way that all the calls known ahead of time and you can test all the possible code paths and inputs then you can get away without asserts. But I find that these scenarios don't manifest themselves that often. Most code executions are impossible to know 100% ahead of time and your unit tests are only ever testing a subset of all possible inputs and execution flows and even if you have 100% bullet proof coverage right now in the future you probably won't and then you're just one innocent change away from letting bugs slip through in your production runs.

> Basically what you're saying is

> "If you never have an accident you don't need seat belts in the car, and since we test drove the vehicle in the factory parking lot and didn't have an accident we decided not to have the seat belts".

Would you trust a manufacturer that added seat belts, but never tested they worked? That's what a runtime assertion is. If it can never fail unless there's a bug, then they can never be tested...

Assertion failure modes are also problematic. Their entire mechanism is blow up and stop running the program. Would you trust a car which crashed if a seatbelt was unplugged?

The test of my assertion is: show me some real-ish code where you think runtime assertions are useful (preferably in backend / web code not a kernel or such).