(PHP 4, PHP 5, PHP 7, PHP 8)
assert — Checks an assertion
DescriptionAssertions can be used to aid debugging. One use case for them is to act as sanity-checks for preconditions that should always be true and that if they aren't upheld this indicates some programming errors. Another use case is to ensure the presence of certain features like extension functions or certain system limits and features.
As assertions can be configured to be eliminated, they should not be used for normal runtime operations like input parameter checks. As a rule of thumb code should behave as expected even if assertion checking is deactivated.
assert() will check that the expectation given in assertion holds. If not, and thus the result is false, it will take the appropriate action depending on how assert() was configured.
The behaviour of assert() is dictated by the following INI settings:
Assert Configure Options Name Default Description Changelog zend.assertions1
1: generate and execute code (development mode)0: generate code but jump around it at runtime-1: do not generate code (production mode)true If false, assert() does not check the expectation and returns true, unconditionally. Deprecated as of PHP 8.3.0. assert.callback null
A user defined function to call when an assertion fails. It's signature should be:
assert_callback(
$file
,
$line
,
$assertion
,
$description = ?
):
voidPrior to PHP 8.0.0, the signature of the callback should be:
assert_callback(
$file
,
$line
,
$assertion
,
$description = ?
):
void Deprecated as of PHP 8.3.0. assert.exceptiontrue If true will throw an AssertionError if the expectation isn't upheld. Deprecated as of PHP 8.3.0. assert.bail false If true will abort execution of the PHP script if the expectation isn't upheld. Deprecated as of PHP 8.3.0. assert.warning true If true, will emit an E_WARNING if the expectation isn't upheld. This INI setting is ineffective if assert.exception is enabled. Deprecated as of PHP 8.3.0. Parameters
assertion
This is any expression that returns a value, which will be executed and the result is used to indicate whether the assertion succeeded or failed.
WarningPrior to PHP 8.0.0, if assertion was a string it was interpreted as PHP code and executed via eval(). This string would be passed to the callback as the third argument. This behaviour was DEPRECATED in PHP 7.2.0, and REMOVED in PHP 8.0.0.
description
If description is an instance of Throwable, it will be thrown only if the assertion is executed and fails.
Note:
As of PHP 8.0.0, this is done prior to calling the potentially defined assertion callback.
Note:
As of PHP 8.0.0, the object will be thrown regardless of the configuration of assert.exception.
Note:
As of PHP 8.0.0, the assert.bail setting has no effect in this case.
If description is a string this message will be used if an exception or a warning is emitted. An optional description that will be included in the failure message if the assertion fails.
If description is omitted. A default description equal to the source code for the invocation of assert() is created at compile time.
assert() will always return true if at least one of the following is true:
zend.assertions=0zend.assertions=-1assert.exception=1assert.bail=1description.If none of the conditions are true assert() will return true if assertion is truthy and false otherwise.
assert. INI settings have been deprecated. 8.0.0 assert() will no longer evaluate string arguments, instead they will be treated like any other argument. assert($a == $b) should be used instead of assert('$a == $b'). The assert.quiet_eval php.ini directive and the ASSERT_QUIET_EVAL constant have also been removed, as they would no longer have any effect. 8.0.0 If description is an instance of Throwable, the object is thrown if the assertion fails, regardless of the value of assert.exception. 8.0.0 If description is an instance of Throwable, no user callback is called even if it set. 8.0.0 Declaring a function called assert() inside a namespace is no longer allowed, and issues E_COMPILE_ERROR. 7.3.0 Declaring a function called assert() inside a namespace became deprecated. Such declaration now emits an E_DEPRECATED. 7.2.0 Usage of a string as the assertion became deprecated. It now emits an E_DEPRECATED notice when both assert.active and zend.assertions are set to 1. Examples
Example #1 assert() example
<?php
assert(1 > 2);
echo 'Hi!';
If assertions are enabled (zend.assertions=1) the above example will output:
Fatal error: Uncaught AssertionError: assert(1 > 2) in example.php:2
Stack trace:
#0 example.php(2): assert(false, 'assert(1 > 2)')
#1 {main}
thrown in example.php on line 2
If assertions are disabled (zend.assertions=0 or zend.assertions=-1) the above example will output:
Example #2 Using a custom message
<?php
assert(1 > 2, "Expected one to be greater than two");
echo 'Hi!';
If assertions are enabled the above example will output:
Fatal error: Uncaught AssertionError: Expected one to be greater than two in example.php:2
Stack trace:
#0 example.php(2): assert(false, 'Expected one to...')
#1 {main}
thrown in example.php on line 2
If assertions are disabled the above example will output:
Example #3 Using a custom exception class
<?php
class ArithmeticAssertionError extends AssertionError {}assert(1 > 2, new ArithmeticAssertionError("Expected one to be greater than two"));
echo 'Hi!';
If assertions are enabled the above example will output:
Fatal error: Uncaught ArithmeticAssertionError: Expected one to be greater than two in example.php:4
Stack trace:
#0 {main}
thrown in example.php on line 4
If assertions are disabled the above example will output:
hodgman at ali dot com dot au ¶16 years ago
As noted on Wikipedia - "assertions are primarily a development tool, they are often disabled when a program is released to the public." and "Assertions should be used to document logically impossible situations and discover programming errors— if the 'impossible' occurs, then something fundamental is clearly wrong. This is distinct from error handling: most error conditions are possible, although some may be extremely unlikely to occur in practice. Using assertions as a general-purpose error handling mechanism is usually unwise: assertions do not allow for graceful recovery from errors, and an assertion failure will often halt the program's execution abruptly. Assertions also do not display a user-friendly error message."
This means that the advice given by "gk at proliberty dot com" to force assertions to be enabled, even when they have been disabled manually, goes against best practices of only using them as a development tool.
sven at rtbg dot de ¶
1 year ago
With the current changes made in PHP 8.3 (deprecating the INI settings affecting assertions) and the increasing amount of open source libraries utilizing `assert()` as an easy means to ensure obscure return cases of PHP core function calls are in fact not triggered (e.g. no NULL or FALSE has been returned, but the useful value), the comment made about assertions only being a tool used during development should be considered invalid.
In addition, static code analysis tools use the knowledge gained from `assert($x instanceof MyClass)` to know the type or types that are possible.
Assertions are actively being used in production code, they are useful, and disabling them would only gain minimal performance benefits because the asserted expression usually is very small.
Use this tool where applicable!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3