Assert - ensure that something never happen.
While we use Exceptions to handle exceptional cases, why we should bother catching errors that we cannot handle? For this purpose, we have asserts.
Asserts are there to catch bugs, and we can have a lot of them without affecting the production performance, since we can remove them in release builds.
There is a very dangerous line of choosing between asserts and exceptions. Unexperienced developers of your team are likely to mess this up. And an assert which should be an exception, which is removed in the release build, is going to produce a panic, instead of allowing to be handled. I think this is the main reason why people are trying to avoid asserts completely.
But if used correctly, asserts are extremely useful for alerting errors that must never occur in the first place, that must be fixed before the product is shipped.
Asserts shouldn’t depend on side-effects, and shouldn’t cause side-effects. They should be strict to the point: check that impossible thing is not happening in our program. For example, if we’re developing a racing car chassis, and there is no place for the engine, we must crash during the development. If we go racing without engine, we’re screwed anyway, there will be no point of handling “no-engine” exception.
Sensitive programs, which are designed to be extra-resilient, cannot allow to crash. Who does want a space satellite to shutdown it’s programs and become an uncontrollable missile? Surprisingly, same approach can be used for game development, where we don’t want to break user experience by crashing. Recovering actions for video games are obviously simpler than for satellites: sometimes no recover even made (like in Godot: print error and continue). But if we ship a program that is initially wrong, we will hit the same error continiously (like RunEngine->“cannot find engine”->Continue->RunEngine->…). Asserts can help to avoid that states leaking to production.
Assertions check that impossible is impossible. Just use them carefully. Extra carefully.