Use of Assertions (2014)(blog.regehr.org)
blog.regehr.org
Use of Assertions (2014)
https://blog.regehr.org/archives/1091
3 comments
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?
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).
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).
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.
Our UI at work is using typescript so these assertions aren't as important as they were in plain JS days.
However runtime types like io-ts are important in network calls since the HTTP client's return type is `unknown`.
However runtime types like io-ts are important in network calls since the HTTP client's return type is `unknown`.
Yeah, typescript obviates so many assertions that using assertions for things that the compiler can’t catch isn’t too burdensome.
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.
Just be careful that assertions aren’t used in place of proper bounds checking.
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'.
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.
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.
Fair enough, performance critical parts are indeed not always the most ideal place for asserts; our asserts also trigger a core dump though.
yeah, i mean, if the app is just gonna quit anyway, it is much nicer for it to quit in a way that communicates that something is actually wrong (instead of silently disappearing) and that the app knows something is terribly wrong...
I agree, but assert is a pretty bad tool to accomplish that. It's much nicer to have signal handlers that will run on a crash so that the user gets some useful log output, etc.
I cried for 15 minutes when I heard contracts wouldn't make it into c++20. Hopefully they will be in c++23.
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)