1: throw when the assertion fails, either by
throwing the object provided as the exception
or by throwing a new AssertionError object if
exception wasn't provided

0: use or generate a
Throwable as described above, but only
generate a warning based on that object rather than throwing it
(compatible with PHP 5 behaviour)

Parámetros

assertion

The assertion. In PHP 5, this must be either a string to
be evaluated or a boolean to be tested. In PHP 7, this may
also be any expression that returns a value, which will be executed and
the result used to indicate whether the assertion succeeded or failed.

description

An optional description that will be included in the failure message if
the assertion fails.

exception

In PHP 7, the second parameter can be a
Throwable object instead of a descriptive
string, in which case this is the object that will be
thrown if the assertion fails and the
assert.exception
configuration directive is enabled.

Valores devueltos

FALSE if the assertion is false, TRUE otherwise.

Historial de cambios

Versión

Descripción

7.0.0

assert() is now a language construct and not a
function. assertion() can now be an expression.
The second parameter is now interpreted either as an
exception (if a
Throwable object is given), or as the
description supported from PHP 5.4.8 onwards.

5.4.8

The description parameter was added. The
description is also now provided to a callback
function in ASSERT_CALLBACK mode as the fourth
argument.

Ejemplos

Traditional assertions (PHP 5 and 7)

Ejemplo #1 Handle a failed assertion with a custom handler

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

Ver también

User Contributed Notes 7 notes

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.

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 favoriteassert('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)