On 31/07/13 09:46, Tyler Romeo wrote:
Interesting concept. I think in C, they are most often used for validating function input, so obviously they can be hit. The Wikipedia articles [[Assertion (software development)]] and [[Precondition]] both mention this usage.
Using assertions to validate function input is indeed a valid usage, but it should be done in ways where they won't be hit. In other words, they should not be used for data validation; they should be used in cases where *the program expects the data to already be valid*.
I think exceptions should be used for that. Like I said in 2012, the implementation of assertions in PHP has lots of problems.
You said previously:
This is why they can be turned off on production servers, because they simply won't happen.
You can't mathematically prove that the behaviour of future developers will follow your expectations. Assertions intended to enforce developer behaviour are routinely hit in production. It's not correct to assume that unit testing will discover all bugs, and that production code will be perfect.
Also, assertions in PHP do not have any performance overhead once they're turned off for production servers, so that won't be an issue either.
That's only the case when the code is encoded as a string, which it's not in Wikibase. And as PleaseStand points out, the fact that assert() can act like eval() can make it hard to verify that code is not an arbitrary script execution vulnerability.
Note that the current thread is about a bug discovered by an assertion logged in production. If we disabled assertions in production, we would not know about it.
-- Tim Starling