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.
assert
(PHP 4, PHP 5, PHP 7, PHP 8)
assert — Prüft, ob eine Assertion (Zusicherung) false ist
Beschreibung
PHP 5 und 7
PHP 7
assert() überprüft den übergebenen Parameter
assertion (Zusicherung) und führt entsprechende
Maßnahmen durch, wenn das Ergebnis false ist.
Traditionelle Assertions (PHP 5 und 7)
Wird der Parameter assertion als Zeichenkette
übergeben, so wird die Zeichenkette von assert() als
PHP-Code interpretiert. Wenn eine boolesche Bedingung als
assertion übergeben wird, wird diese Bedingung, die
eventuell mit assert_options() definiert wurde, nicht
als Parameter an die Assertion-Funktion weitergegeben. Die Bedingung wird
in eine Zeichenkette umgewandelt, bevor die Handler-Funktion aufgerufen
wird, und das boolesche false wird in eine leere Zeichenkette
umgewandelt.
assert() sollte nur zum Debuggen des Codes verwendet
werden. Es kann für Plausibilitätsprüfungen verwendet werden, um auf
Bedingungen zu prüfen, die immer true sein sollten, und die andernfalls
Programmierfehler anzeigen, oder um auf die Verfügbarkeit bestimmter
Merkmale, wie Erweiterungsfunktionen oder bestimmte Systembeschränkungen
und Eigenschaften, zu prüfen.
Assertions sollten nicht für normale Laufzeitoperationen wie die Überprüfung von Eingaben verwendet werden. Als Faustregel sollte der Code immer korrekt funktionieren können, auch wenn die Assertion-Prüfung deaktiviert ist.
Die Optionen für assert() können über die Funktion assert_options() oder durch .ini-Einstellungen, die in der Handbuchseite dieser Funktion beschrieben werden, konfiguriert werden.
Die Funktion assert_options() und/oder die
Konfigurationsoption ASSERT_CALLBACK ermöglichen es,
eine Funktion anzugeben, die bei fehlgeschlagenen Assertions aufgerufen
wird.
Callback-Funktionen im Zusammenhang mit assert() sind insbesondere nützlich, um beispielsweise automatisierte Tests durchzuführen, da die Callback-Funktion über die Information verfügt, von welcher Stelle sie aufgerufen wurde. Auch wenn diese Information mit anderen Methoden zugänglich ist, macht es die Verwendung von Assertions viel schneller und leichter!
Die Callback-Funktion wird mit drei Parametern aufgerufen. Der erste
Parameter enthält den Namen des Skripts, in dem die Assertion fehlschlug,
der zweite Parameter die Zeilennummer und der dritte Parameter enthält die
über assertion angegebene Bedingung (falls
vorhanden, wobei Literale wie 1 oder "zwei" in diesem Argument nicht
übergeben werden). Nutzer von PHP 5.4.8 und höher können auch ein viertes
optionales Argument angeben, das die Beschreibung
description enthält, die an
assert() übergeben wird.
Expectations (Annahmen) (nur PHP 7)
assert() ist in PHP 7 ein Sprachkonstrukt, das die Definition von Expectations ermöglicht: Assertions, die in Entwicklungs- und Testumgebungen wirken, aber so optimiert werden, dass sie in Produktionsumgebungen keinen Mehraufwand verursachen.
Während assert_options() noch immer verwendet werden kann, um das oben beschriebene Verhalten aus Gründen der Abwärtskompatibilität zu steuern, sollte Code, der nur für PHP 7 geschrieben wird, die beiden neuen Konfigurationsoptionen zur Steuerung von assert() verwenden und nicht assert_options() aufrufen.
| Option | Vorgabewert | Mögliche Werte |
|---|---|---|
| zend.assertions | 1 |
|
| assert.exception | 0 |
|
Parameter-Liste
-
assertion -
Die Assertion. In PHP 5 muss dies entweder ein auszuwertender String sein, oder ein zu testender bool. In PHP 7 kann dies auch ein beliebiger Ausdruck sein, der einen Wert zurückgibt, der ausgeführt und dessen Ergebnis verwendet wird, um anzuzeigen, ob die Zusicherung erfolgreich war oder fehlschlug.
WarnungDie Verwendung eines Strings als
assertionist von PHP 7.2 an MISSBILLIGT. -
description -
Eine optionale Beschreibung, die in der Fehlermeldung enthalten ist, wenn die
assertionfehlschlägt. Von PHP 7 an wird, falls keine Beschreibung angegeben wurde, eine Standardbeschreibung, die gleich dem Quellcode des Aufrufs von assert() ist, bereitgestellt. -
exception -
In PHP 7 kann der zweite Parameter ein Throwable-Objekt anstatt eines beschreibenden Strings sein, so dass dieses Objekt als Exception geworfen wird, wenn die Zusicherung fehlschlägt und die Konfigurationsoption assert.exception aktiviert ist.
Rückgabewerte
false, wenn die Assertion nicht erfüllt ist, anderfalls true.
Changelog
| Version | Beschreibung |
|---|---|
| 8.0.0 |
Die Deklaration einer Funktion namens assert()
innerhalb eines Namensraums ist nicht mehr erlaubt und führt zu einem
Fehler der Stufe E_COMPILE_ERROR.
|
| 7.3.0 |
Die Deklaration einer Funktion namens assert()
innerhalb eines Namensraums ist veraltet und gibt nun einen
E_DEPRECATED-Hinweis aus.
|
| 7.2.0 |
Die Verwendung eines Strings als assertion
wird missbilligt. Dies erzeugt nun einen
E_DEPRECATED-Hinweis, wenn sowohl
assert.active als auch
zend.assertions auf
1 gesetzt sind.
|
| 7.0.0 |
assert() ist nun ein Sprachkonstrukt und keine
Funktion mehr. assertion kann nun ein Ausdruck
sein. Der zweite Parameter wird nun entweder als
exception interpretiert (wenn ein
Throwable-Objekt übergeben wird), oder als
description, was ab PHP 5.4.8 unterstützt wird.
|
Beispiele
Traditionelle Assertions (PHP 5 und 7)
Beispiel #1 Überprüfung mit benutzerdefinierter Funktion
<?php
// Assertions aktivieren und stummschalten
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);
// Eine Handlerfunktion erzeugen
function my_assert_handler($file, $line, $code)
{
echo "<hr>Assertion fehlgeschlagen:
Datei '$file'<br />
Zeile '$line'<br />
Code '$code'<br /><hr />";
}
// Den Callback definieren
assert_options(ASSERT_CALLBACK, 'my_assert_handler');
// Eine Assertion, die fehlschlagen sollte
assert('mysql_query("")');
?>
Beispiel #2 Verwendung eines benutzerdefinierten Handlers um eine Beschreibung anzuzeigen
<?php
// Assertions aktivieren und stummschalten
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);
// Eine Handlerfunktion erzeugen
function my_assert_handler($file, $line, $code, $desc = null)
{
echo "Assertion fehlgeschlagen in $file:$line: $code";
if ($desc) {
echo ": $desc";
}
echo "\n";
}
// Den Callback definieren
assert_options(ASSERT_CALLBACK, 'my_assert_handler');
// Assertions, die fehlschlagen sollten
assert('2 < 1');
assert('2 < 1', 'Zwei ist kleiner als Eins');
?>
Das oben gezeigte Beispiel erzeugt folgende Ausgabe:
Assertion fehlgeschlagen in test.php:21: 2 < 1 Assertion fehlgeschlagen in test.php:22: 2 < 1: Zwei ist kleiner als Eins
Expectations (nur PHP 7)
Beispiel #3 Expectations ohne benutzerdefinierte Exception
<?php
assert(true == false);
echo 'Hi!';
?>
Ist zend.assertions auf 0 gesetzt, gibt das obige Beispiel folgendes aus:
Hi!
Ist zend.assertions auf 1 gesetzt und assert.exception auf 0, gibt das obige Beispiel folgendes aus:
Warning: assert(): assert(true == false) failed in - on line 2 Hi!
Ist zend.assertions auf 1 gesetzt und assert.exception auf 1, gibt das obige Beispiel folgendes aus:
Fatal error: Uncaught AssertionError: assert(true == false) in -:2
Stack trace:
#0 -(2): assert(false, 'assert(true == ...')
#1 {main}
thrown in - on line 2
Beispiel #4 Expectations mit einer benutzerdefinierten Exception
<?php
class CustomError extends AssertionError {}
assert(true == false, new CustomError('True ist nicht false!'));
echo 'Hi!';
?>
Ist zend.assertions auf 0 gesetzt, gibt das obige Beispiel folgendes aus:
Hi!
Ist zend.assertions auf 1 gesetzt und assert.exception auf 0, gibt das obige Beispiel folgendes aus:
Warning: assert(): CustomError: True ist nicht false! in -:4
Stack trace:
#0 {main} failed in - on line 4
Hi!
Ist zend.assertions auf 1 gesetzt und assert.exception auf 1, gibt das obige Beispiel aus:
Fatal error: Uncaught CustomError: True ist nicht false! in -:4
Stack trace:
#0 {main}
thrown in - on line 4
add a note
User Contributed Notes 9 notes
hodgman at ali dot com dot au ¶
13 years ago
Tom ¶
2 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.
mail<at>aaron-mueller.de ¶
15 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);
?>
Krzysztof 'ChanibaL' Bociurko ¶
14 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...)
Julien MOREAU aka PixEye ¶
2 days 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;
jason at jaypha dot com ¶
4 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.
uramihsayibok, gmail, com ¶
11 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)
office dot stojmenovic at gmail dot com ¶
8 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);
?>
