3 ms·
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
by stinos 6y ago
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'.
- keeganpoppen 6y agoyeah, 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...
- dahfizz 6y agoI 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.
- dahfizz 6y agoIn 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 6y agoFair enough, performance critical parts are indeed not always the most ideal place for asserts; our asserts also trigger a core dump though.