Why are assertions compiled out of production builds (other than performance)?

Question

The typical argument for removing assertions from production code is performance. This doesn't make sense to me. Yes, stripping a few assertions out of the performance-critical 5% or so of your code can be a useful optimization. For the other 95%, though, they probably have no measurable effect, and asserts can only increase the likelihood that, if your code has a bug, it will fail fast and in an easy to diagnose way.

I do most of my programming in D, which has an enforce() function that does basically what assert() does except that it stays in release builds. I typically find myself using enforce() most of the time, and assert() only in a few places where enforce() would be too expensive.

Is there any other reason besides performance to remove asserts from release builds? If not, why don't languages make the default behavior of asserts to always execute even in release builds, and provide a second function that's more verbose and harder to remember, something like expensiveAssert() that is stripped out of release builds and recommend its use only in performance-critical parts of your code?

Answer 1

It's not just that. I think having asserts kept in production builds would add to people's paranoia about what text (and/or source snippets) ends up in shipped binaries (think what code comments would be like if they ended up in shipped binaries!), which in turn would discourage use of assertions.

Your mileage may vary.

Answer 2

I think assert() was meant as a pure developers tool in the first place.

A piece of software for end-users should provide some kind error handling (by logging and/or displaying a message to the user). assert() does not provide error handling.

However, I typically use my own release and debug assert functions. Both release and debug assert are only used for unusual errors - which should never occur. But they give a useful error message (useful for the developer, usually not so helpful for the end-user).

Errors that may occur (input/output, mis-configuration, ..) are explicitly handled and give a message to the user.

Answer 3

My answer would be that assertions prematurely abort execution of the program, often when it is not necessary. Although one might be paranoid because a skipped assertion results in undetermined behavior, the program may be able to limp along anyway. Assertions can be really annoying and stupid when you run into them as a user. As in, why can't this game deal with ONE invalid texture?!!

Although assertions are a great way to catch errors quickly when developing, users hate them (in my opinion).

Answer 4

i think having assertions in production code is OK. disabling it makes you lose some insights about problems in your system in production. and i am always interested how my program/system behaves+fails in production. in my view the best "test-data" to improve your system often comes through real users.

what i prefer:

• keep assertions in production code
• log with good information in case assert fails
• handle the assertion error (->never show the user a stack-trace)
• after a while screen log-files for assert failures and fix your code (to me assertions are programming or contract-violation error-triggers)