assert

(PHP 4, PHP 5, PHP 7, PHP 8)

assertChecks an assertion

Description

assert(mixed $assertion, Throwable|string|null $description = null): bool

assert() is not a function but a language construct. allowing for the definition of expectations: assertions that take effect in development and testing environments, but are optimised away to have zero cost in production.

Assertions should be used as a debugging feature only. 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.assertions 1
  • 1: generate and execute code (development mode)
  • 0: generate code but jump around it at runtime
  • -1: do not generate code (production mode)
 
assert.active true If false, assert() does not check the expectation and returns true, unconditionally.  
assert.callback null A user defined function to call when an assertion fails. It's signature should be:
assert_callback(
    string $file,
    int $line,
    null $assertion,
    string $description = ?
): void
Prior to PHP 8.0.0, the signature of the callback should be:
assert_callback(
    string $file,
    int $line,
    string $assertion,
    string $description = ?
): void
assert.exception true If true will throw an AssertionError if the expectation isn't upheld.  
assert.bail false If true will abort execution of the PHP script if the expectation isn't upheld.  
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.  
The options starting with assert. can be configured via assert_options(). However, this is not recommended.

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.

Warning

Prior 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.

Return Values

false if assertion is false, true otherwise.

Changelog

Version Description
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

Expectations

<?php
assert
(true == false);
echo
'Hi!';
?>

With zend.assertions set to 0, the above example will output:

Hi!

With zend.assertions set to 1 and assert.exception set to 0, the above example will output:

Warning: assert(): assert(true == false) failed in - on line 2
Hi!

With zend.assertions set to 1 and assert.exception set to 1, the above example will output:

Fatal error: Uncaught AssertionError: assert(true == false) in -:2
Stack trace:
#0 -(2): assert(false, 'assert(true == ...')
#1 {main}
  thrown in - on line 2

Example #1 Expectations with a custom exception

<?php
class CustomError extends AssertionError {}

assert(true == false, new CustomError('True is not false!'));
echo
'Hi!';
?>

With zend.assertions set to 0, the above example will output:

Hi!

With zend.assertions set to 1 and assert.exception set to 0, the above example will output:

Warning: assert(): CustomError: True is not false! in -:4
Stack trace:
#0 {main} failed in - on line 4
Hi!

With zend.assertions set to 1 and assert.exception set to 1, the above example will output:

Fatal error: Uncaught CustomError: True is not false! in -:4
Stack trace:
#0 {main}
  thrown in - on line 4

Evaluated code assertions (PHP 7 only)

With evaluated code assertions, assert() callbacks can be particularly useful as the code used for the assertion is passed to the callback alongside information on where the assertion was done.

Example #2 Handle a failed assertion with a custom handler

<?php
// Activate assert and make it quiet
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);

// Create a handler function
function my_assert_handler($file, $line, $code)
{
echo
"<hr>Assertion Failed:
File '
$file'<br />
Line '
$line'<br />
Code '
$code'<br /><hr />";
}

// Set up the callback
assert_options(ASSERT_CALLBACK, 'my_assert_handler');

// Make an assertion that should fail
$array = [];
assert('count($array);');
?>

Output of the above example in PHP 7.2:

Deprecated: assert(): Calling assert() with a string argument is deprecated in test.php on line 21
<hr>Assertion Failed:
        File 'test.php'<br />
        Line '21'<br />
        Code 'count($array);'<br /><hr />

Output of the above example in PHP 7.1:

<hr>Assertion Failed:
        File 'test.php'<br />
        Line '21'<br />
        Code 'count($array);'<br /><hr />

Example #3 Using a custom handler to print a description

<?php
// Activate assert and make it quiet
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);

// Create a handler function
function my_assert_handler($file, $line, $code, $desc = null)
{
echo
"Assertion failed at $file:$line: $code";
if (
$desc) {
echo
": $desc";
}
echo
"\n";
}

// Set up the callback
assert_options(ASSERT_CALLBACK, 'my_assert_handler');

// Make an assertion that should fail
assert('2 < 1');
assert('2 < 1', 'Two is less than one');
?>

Output of the above example in PHP 7.2:

Deprecated: assert(): Calling assert() with a string argument is deprecated in test.php on line 21
Assertion failed at test.php:21: 2 < 1

Deprecated: assert(): Calling assert() with a string argument is deprecated in test.php on line 22
Assertion failed at test.php:22: 2 < 1: Two is less than one

Output of the above example in PHP 7.1:

Assertion failed at test.php:21: 2 < 1
Assertion failed at test.php:22: 2 < 1: Two is less than one

See Also

add a note

User Contributed Notes 9 notes

up
26
hodgman at ali dot com dot au
15 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.
up
4
Tom
4 years ago
When migrating older code to PHP 7.2+, you may get E_DEPRECATED warnings for every call to assert() you ever wrote, urging you to not pass the assertion as a string.

It may be tempting to just run a regular expression across your files to convert all strings within "assert(...)" to statements. But, before you do that, be aware of the following caveat!

For example, this code simply asserts that $input is not empty.

assert('$input;');

This works, because the string passed to assert() is evaluated as a PHP statement and the result cast to Boolean.

If you want to have an equivalent statement that doesn't pass the first parameter as a string, your regular expression should rewrite this statement as:

assert((bool) ($input));

However, this looks a bit bulky and it is tempting to instead opt for the more direct approach to convert the above line to this:

assert($input);

But! This new statement will do one of three things:

1) Looks as if it worked as intended because $input just happens to be Boolean to begin with
2) Throw a parse error if $input is a string (best case)
3) Allow an attacker on a poorly configured server to execute arbitrary PHP-Code (worst case)

The reason is that, even though on PHP 7.2+ a E_DEPRECATED warning is raised, if assert() finds the first parameter to be a string, it will still execute it as PHP-Code, just as if it was called with a string to begin with.

If an attacker finds a way to manipulate the contents of $input, you might end up with a remote code execution vulnerability. So just be extra careful when migrating assertions.
up
6
mail<at>aaron-mueller.de
17 years ago
Here is a simple demonstration of Design By Contract with PHP

<?php

assert_options
(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_BAIL, 1);
assert_options(ASSERT_CALLBACK, 'dcb_callback');

function
dcb_callback($script, $line, $message) {
echo
"<h1>Condition failed!</h1><br />
Script: <strong>
$script</strong><br />
Line: <strong>
$line</strong><br />
Condition: <br /><pre>
$message</pre>";
}

// Parameters
$a = 5;
$b = 'Simple DCB with PHP';

// Pre-Condition
assert('
is_integer($a) &&
($a > 0) &&
($a < 20) &&

is_string($b) &&
(strlen($b) > 5);
'
);

// Function
function combine($a, $b) {
return
"Kombined: " . $b . $a;
}

$result = combine($a, $b);

// Post-Condition
assert('
is_string($result) &&
(strlen($result) > 0);
'
);

// All right, the Function works fine
var_dump($result);

?>
up
4
Krzysztof &#39;ChanibaL&#39; Bociurko
16 years ago
Note that func_get_args() should be used carefully and never in a string! For example:

<?php
function asserted_normal($a, $b) {
assert(var_dump(func_get_args()));
}
function
asserted_string($a, $b) {
assert('var_dump(func_get_args())');
}
?>

<?php asserted_normal(1,2) ?> prints
array(2) {
[0]=>
int(1)
[1]=>
int(2)
}

but <?php asserted_string(3,4) ?> prints
array(1) {
[0]=>
string(25) "var_dump(func_get_args())"
}

This is because of that the string passed to assert() is being evaled inside assert, and not your function. Also, note that this works correctly, because of the eval scope:

<?php
function asserted_evaled_string($a, $b) {
assert(eval('var_dump(func_get_args())'));
}
asserted_evaled_string(5,6);
?>
array(2) {
[0]=>
int(5)
[1]=>
int(6)
}

(oh, and for simplicity's sake the evaled code doesn't return true, so don't worry that it fails assertion...)
up
1
Julien MOREAU aka PixEye
2 years ago
In order to change zend.assertions or assert.exception values, try with the ini_set() function but be aware that it may fail.

Example:
<?php
$ret
= @ini_set('zend.assertions', '1');
if (
$ret === false) echo 'ini_set() failed before line ', __LINE__, PHP_EOL;
up
-1
jason at jaypha dot com
6 years ago
You can take advantage of how assert is handled to use it for crude conditional compilation.

For example

<?php
assert
(print("Some debug message\n"));
assert(($val = "dev") || true);
?>

Since print() always returns 1, the topmost assertion will pass. For others, you may need to add a || true. Always enclose the expression in ().

In a development environment where zend.assertions=1, the above code will execute. In production environments where zend.assertions=-1, it wont even compile, thus not burdening performance.

Another, more real world, example.

<?php
$cssSrc
= 'https://code.jquery.com/jquery-3.2.1.min.js';
assert(($cssSrc = 'http://dev.local/jquery-3.2.1.js') || true);
echo
"<link rel='stylesheet' type='text/css' href='$cssSrc'/>\n";
?>

In a production environment, The website will use the minified version from the CDN. In a development environment, a development version, sourced locally, will be used instead.

Note: This will not work for everything. Only code that can be embedded in an expression will work.
up
-5
uramihsayibok, gmail, com
13 years ago
There's a nice advantage to giving assert() some code to execute, as a string, rather than a simple true/false value: commenting.

<?php

assert
('is_int($int) /* $int parameter must be an int, not just numeric */');

// and my personal favorite
assert('false /* not yet implemented */');

?>

The comment will show up in the output (or in your assertion handler) and doesn't require someone debugging to go through your code trying to figure out why the assertion happened. That's no excuse to not comment your code, of course.

You need to use a block comment (/*...*/) because a line comment (//...) creates an "unexpected $end" parse error in the evaluated code. Bug? Could be.
(You can get around it with "false // not yet implemented\n" but that screws up the message)
up
-8
office dot stojmenovic at gmail dot com
10 years ago
Example from Ikac Framework how they use assert()

<?php

/**
* Set Assertion Debug
*
* This method will check the given assertion and take appropriate -
* action if its result is FALSE.
*
* This file is part of Ikac Framework.
*
* @package Ikac Framework
* @author Ivan Stojmenovic Ikac <contact.@stojmenovic.info>
*
* @param mixed $assertion The assertion.
* @param mixed $callback Callback to call on failed assertions
* @param array $options Set the various control options or just query their current settings.
* @param string $description An optional description that will be included in the failure message if the assertion fails.
*/
public function setAssertionDebug($assertion, $callback, array $options, $description = null)
{
if (
is_array($options)) {
foreach (
$options AS $option => $value) {
assert_options($option, $value);
}
}
if (
$callback) {
assert_options(ASSERT_CALLBACK, $callback);
}

return
assert($assertion, $description);
}
?>

How to use:

<?php
use Ikac\Component\SystemBehaviour\OptionsInfo;

$system = new OptionsInfo();

$option = array(ASSERT_ACTIVE => 1,ASSERT_WARNING => 0,ASSERT_QUIET_EVAL => 1);

$system->setAssertionDebug('2<1', function(){
echo
"Assertion failed";
},
$option);

?>
up
-4
Ben
7 years ago
if there was no 'warning' message when assertion failed (FALSE), try reset the error handler:
<?php
set_error_handler
( null );
To Top