
Use of Assertions (2014) - kqr
https://blog.regehr.org/archives/1091
======
skrebbel
Does anyone here use assertions in anger in a web app? I sort of feel that
frontend app that is jock-full with assertions and logs every assertion
failure to a Sentry type service, would be much easier to get error-free.
Almost to the point of needing significantly fewer unit tests, maybe. Is there
any downsides to this approach? Do people do this?

~~~
timclark
Having worked on multiple systems that have done similar things to this, I'd
fall on the side of no!

If you're not really careful the assertions will quickly obscure the actual
logic (as does logging), a careless engineer can easily add a bad assertion
and fill up your monitoring system, another careless engineer can write a
complicated but broken assertion without any tests - they've all happened to
me on multiple production systems.

Eiffel style pre and post conditions might be a solution as the assertions are
kept away from the main code path in the method signatures - but at that point
a modern statically typed language might give you more value (preferably with
null safety and sum types).

~~~
foobarian
My worst nightmare are abandoned assertions/errors. People logs them "just in
case" and forget about them, years later you have huge volume in the logging
system that nobody looks at.

------
dahfizz
My company uses assertions pretty aggressively, but they are compiled out in
release builds. This serves as free unit tests and greatly improves debugging
because we get a core dump whenever a bug occurs.

~~~
stinos
Used to do that, but now we leave them in.. It's not like bugs don't happen in
release builds (worse, the most obscure ones were the ones which _only_
happened in release builds) and while a dialog box saying clearly 'developer
made a mistake on line X, please copy-paste this and send it to ...' is very
much in-your-face, it does usually lead to a clearer bug report than the
customer saying 'your app just quit' or 'I got a message saying something
about access violation and then your app quit'.

~~~
dahfizz
In my case, it's mostly for performance reasons that they are left out in
release builds. I work in extremely performance sensitive fintech, where the
cost of a couple hundred if statements in a critical code path is a big deal.

We have signal handlers and all that so the user still gets a core dump
whenever the program crashes, it just takes more digging to find exactly where
the bug is vs where it manifests.

~~~
stinos
Fair enough, performance critical parts are indeed not always the most ideal
place for asserts; our asserts also trigger a core dump though.

------
drummer
I cried for 15 minutes when I heard contracts wouldn't make it into c++20.
Hopefully they will be in c++23.

~~~
mhh__
They should've just gone for the system that D has. It's dead simple, easy to
standardize and more flexible (The contracts themselves are effectively user
defined so you can be as simple or complicated as you like)

