ConFoo 2025

assert

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

assertÜberprüft eine Assertion (Zusicherung)

Beschreibung

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

assert() ermöglicht es, Expectations (Annahmen) zu definieren: Zusicherungen, die in Entwicklungs- und Testumgebungen wirken, aber so optimiert sind, dass sie in Produktionsumgebungen keinen Mehraufwand verursachen.

Zusicherungen sollten nur zur Fehlersuche verwendet werden. So können sie z. B. für Plausibilitätsprüfungen für Vorbedingungen verwendet werden, die immer true sein sollten, und die andernfalls auf Programmierfehler hinweisen. Ein weiterer Anwendungsfall ist, sicherzustellen, dass bestimmte Merkmale wie Funktionen von Erweiterungen oder bestimmte Grenzwerte und Eigenschaften des Systems vorhanden sind.

Da Zusicherungen so konfiguriert werden können, dass sie deaktiviert werden, sollten sie nicht für normale Laufzeitoperationen wie die Überprüfung von Eingabeparametern verwendet werden. Als Faustregel gilt, dass sich der Code auch bei deaktivierter Zusicherungsüberprüfung so verhalten sollte wie erwartet.

assert() prüft, ob die in assertion angegebene Annahme zutrifft. Wenn dies nicht der Fall ist und das Ergebnis somit false ist, werden die entsprechenden Maßnahmen ergriffen, je nachdem wie assert() konfiguriert wurde.

Das Verhalten von assert() wird durch die folgenden INI-Einstellungen bestimmt:

Konfigurationsoptionen für assert
Name Standard Beschreibung Changelog
zend.assertions 1
  • 1: erzeugt Code und führt ihn aus (Entwicklungsmodus).
  • 0: erzeugt Code, aber führt ihn zur Laufzeit nicht aus.
  • -1: erzeugt keinen Code (Produktionsmodus).
 
assert.active true Wenn false, prüft assert() die Annahme nicht und gibt automatisch true zurück. Seit PHP 8.3.0 veraltet.
assert.callback null

Eine benutzerdefinierte Funktion, die aufgerufen wird, wenn eine Zusicherung fehlschlägt. Sie sollte die folgende Signatur haben:

assert_callback(
    string $file,
    int $line,
    null $assertion,
    string $description = ?
): void

Vor PHP 8.0.0 musste die Signatur des Callbacks wie folgt lauten:

assert_callback(
    string $file,
    int $line,
    string $assertion,
    string $description = ?
): void

Seit PHP 8.3.0 veraltet.
assert.exception true Wenn true, wird ein AssertionError ausgelöst, wenn die Erwartung nicht erfüllt wird. Seit PHP 8.3.0 veraltet.
assert.bail false Wenn true, wird die Ausführung des PHP-Skripts gestoppt, wenn die Erwartung nicht erfüllt wird. Seit PHP 8.3.0 veraltet.
assert.warning true Wenn true, wird eine E_WARNING ausgegeben, wenn die Erwartung nicht erfüllt wird. Diese INI-Einstellung hat keine Auswirkung, wenn assert.exception aktiviert ist. Seit PHP 8.3.0 veraltet.

Parameter-Liste

assertion

Dies ist ein beliebiger Ausdruck, der einen Wert zurückgibt, der ausgeführt wird und dessen Ergebnis verwendet wird, um anzuzeigen, ob die Zusicherung erfolgreich war oder fehlschlug.

Warnung

Vor PHP 8.0.0 wurde assertion, wenn es vom Typ string war, als PHP-Code interpretiert und über eval() ausgeführt. Diese Zeichenkette wurde dann als drittes Argument an den Callback übergeben. Dieses Verhalten war in PHP 7.2.0 MISSBILLIGT, und wurde in PHP 8.0.0 ENTFERNT.

description

Wenn description eine Instanz von Throwable ist, wird sie nur ausgelöst, wenn die assertion ausgeführt wird und fehlschlägt.

Hinweis:

Seit PHP 8.0.0 wird dies durchgeführt bevor ein möglicherweise definierter Zusicherungs-Callback aufgerufen wird.

Hinweis:

Seit PHP 8.0.0 wird das Objekt unabhängig von der Einstellung von assert.exception ausgelöst.

Hinweis:

Seit PHP 8.0.0 hat die Einstellung von assert.bail in diesem Fall keine Wirkung mehr.

Wenn description vom Typ String ist, wird diese Nachricht verwendet, wenn eine Exception oder eine Warnung ausgegeben wird. Eine optionale Beschreibung, die in die Fehlermeldung aufgenommen wird, wenn die assertion fehlschlägt.

description kann weggelassen werden. Die Standardbeschreibung entspricht dem Quellcode für den Aufruf von assert() und wird zur Kompilierzeit erstellt.

Rückgabewerte

Wenn mindestens eine der folgenden Bedingungen erfüllt ist, gibt assert() immer true zurück:

  • zend.assertions=0
  • zend.assertions=-1
  • assert.exception=1
  • assert.bail=1
  • An description wird ein benutzerdefiniertes Exception-Objekt übergeben.

Wenn keine der Bedingungen wahr ist, gibt assert() true zurück, sofern assertion wahr ist, ansonsten false.

Changelog

Version Beschreibung
8.3.0 Alle INI-Einstellungen für assert. sind veraltet.
8.0.0 assert() wertet Zeichenketten nicht mehr aus, sondern behandelt sie stattdessen wie jeden anderen Parameter. Anstelle von assert('$a == $b') sollte assert($a == $b) verwendet werden. Die php.ini-Direktive assert.quiet_eval und die Konstante ASSERT_QUIET_EVAL wurden ebenfalls entfernt, da sie keine Auswirkungen mehr haben.
8.0.0 Wenn description eine Instanz von Throwable ist, wird nun ein Objekt ausgelöst, wenn die Zusicherung fehlschlägt, unabhängig vom Wert von assert.exception.
8.0.0 Wenn description eine Instanz von Throwable ist, wird kein Benutzer-Callback aufgerufen, auch wenn er gesetzt ist.
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.

Beispiele

Beispiel #1 assert()-Beispiel

<?php
assert
(1 > 2);
echo
'Hi!';

Falls Zusicherungen aktiviert sind (zend.assertions=1), gibt das obige Beispiel folgendes aus:

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

Falls Zusicherungen deaktiviert sind (zend.assertions=0 oder zend.assertions=-1), gibt das obige Beispiel folgendes aus:

Hi!

Beispiel #2 Verwenden einer benutzerdefinierten Meldung

<?php
assert
(1 > 2, "Es wurde erwartet, dass eins größer ist als zwei");
echo
'Hi!';

Falls Zusicherungen aktiviert sind, gibt das obige Beispiel folgendes aus:

Fatal error: Uncaught AssertionError: Es wurde erwartet, dass eins größer ist als zwei in example.php:2
Stack trace:
#0 example.php(2): assert(false, 'Es wurde erwartet,...')
#1 {main}
  thrown in example.php on line 2

Falls Zusicherungen deaktiviert sind, gibt das obige Beispiel folgendes aus:

Hi!

Beispiel #3 Verwenden einer benutzerdefinierten Exception-Klasse

<?php
class ArithmeticAssertionError extends AssertionError {}

assert(1 > 2, new ArithmeticAssertionError("Es wurde erwartet, dass eins größer ist als zwei"));
echo
'Hi!';

Falls Zusicherungen deaktiviert sind, gibt das obige Beispiel folgendes aus:

Fatal error: Uncaught ArithmeticAssertionError: Es wurde erwartet, dass eins größer ist als zwei in example.php:4
Stack trace:
#0 {main}
  thrown in example.php on line 4

Falls Zusicherungen deaktiviert sind, gibt das obige Beispiel folgendes aus:

Hi!

Siehe auch

add a note

User Contributed Notes 2 notes

up
33
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.
up
9
sven at rtbg dot de
9 months 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!
To Top