note 79476 rejected from function.assert by danbrown

Note Submitter: dexen + goofy _ pl ---- Summary: turn assert() checking in production site, and use plain conditionals coupled with error reporting (trigger_error() or throw) for check that must be performed always. I'd like to support oppinion of Matthew (matthew, at teh dot ath dot cx), and oppose the one of Tom (tom russo at gmail dot com). When developing a program, you clearly want to check for various conditions, for example input validity and conformance of results of computation to various constraints, like database format. However, while some of the checks are mandatory, because supplied data varies with every request, others aren't, for example result of computations. Well written function will behave reasonably for *any* input -- either compute result/perform action, or signal error, be it return value or exception. And if a function takes input from trusted source, like another function you wrote, you don't need to check for all possible problems. This is important distinction -- while developing, your incomplete and/or buggy function may return invalid result. Or a wrong kind of argument may be passed to your function. Or the code may, in some corner case, generate suprious data. This is where assertion comes in hand, to detect such conditions, signal to developer, and possibly stop execution, to prevent data loss. However, the assumption is, that you ship code not earlier than the functions are complete. This means, you should not need checking of such conditions. If your code is incomplete, you don't ship, simple as that. Or label it as test version. For checks that are required for every execution of code, you want plain IFs, is_* functions and so on, coupled with trigger_error() and/or throw statement. Wrapping assertions around those will not help it at all, even slightly impact performance. There simply is no point in using assert() there. You can get as detailed error reports with throw and exception handlers or with trigger_error() as with assert(). On the other hand, for checks that are needed only during development, you use assert(' condition ' ), since it can be turned off, and no performance impact occurs. There is also a catch: error report form assert() may be verbose enough to reveal confidential data. What if you forget to turn assertion checking off and one is triggered in database connection setup code, with stack backtrace revealing DB username and password?