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).
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.
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'.
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)
[+] [-] skrebbel|5 years ago|reply
[+] [-] timclark|5 years ago|reply
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).
[+] [-] emptysea|5 years ago|reply
However runtime types like io-ts are important in network calls since the HTTP client's return type is `unknown`.
[+] [-] dahfizz|5 years ago|reply
[+] [-] stinos|5 years ago|reply
[+] [-] fsociety|5 years ago|reply
[+] [-] drummer|5 years ago|reply
[+] [-] mhh__|5 years ago|reply