Assertions in Production Code? (2008)
At my work (hosted enterprise webapp), both the frontend and backend have both an `assert` function and an `assertAndContinue` function. `assert` always crashes on failure, and `assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review), but there are reasons to use plain assert:<p>• In some cases, crashing is a better user experience than proceeding in an unknown state. Usually this is on the backend when data integrity is at risk, but could be on the frontend when we&#x27;re at risk of making a server call with the wrong arguments. But usually, pretty much anything that doesn&#x27;t crash is better than crashing.<p>• `assertAndContinue` requires that you have a reasonable fallback. If code is going to crash the next line anyway, there&#x27;s no point in `assertAndContinue`. In most cases, it&#x27;s easy, but sometimes it takes real engineering, like building in an error state into the UI component that skips downstream code. When there isn&#x27;t an obvious fallback, using `assertAndContinue` is a judgement call based on the difficulty of implementing a real fallback, the likelihood of the bug actually happening, and severity if the bug does trigger.