Verhalten bei fehlenden Konstanten

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Kann man bei PHP das Verhalten bei fehlenden Konstanten eigentlich irgendwo festlegen?

Ich fände es äußerst sinnvoll, wenn man das Standardverhalten, bei einer fehleneden Konstantedefinition einfach deren Bezeichner als String anzunehmen, abschalten könnte, Besser würde mir noch gefallen, wenn man sogar festlegen könnte, ob es eine Notice (Verhalten wie bisher?), eine Warnung oder einen Fehler mit Abbruch geben soll.

Spirituelle Grüße
Euer Robert

[ChrisB]

Hi,

Kann man bei PHP das Verhalten bei fehlenden Konstanten eigentlich irgendwo festlegen?

Ich fände es äußerst sinnvoll, wenn man das Standardverhalten, bei einer fehleneden Konstantedefinition einfach deren Bezeichner als String anzunehmen, abschalten könnte,

Nein, das ist nicht möglich.

Besser würde mir noch gefallen, wenn man sogar festlegen könnte, ob es eine Notice (Verhalten wie bisher?), eine Warnung oder einen Fehler mit Abbruch geben soll.

Mit einem eigenen Error-Handler würde das vermutlich gehen – ob’s den Aufwand wert ist, ist eine andere Frage.

MfG ChrisB

[Jörg Reinholz]

Ich fände es äußerst sinnvoll, wenn man das Standardverhalten, bei einer fehleneden Konstantedefinition einfach deren Bezeichner als String anzunehmen, abschalten könnte,

Nein, das ist nicht möglich.

Ist es doch. Man kann PHP ein Verhalten wie bei "use strict" (Perl) bzw. "option explicit" (VBA) beibringen.

Mit einem eigenen Error-Handler würde das vermutlich gehen – ob’s den Aufwand wert ist, ist eine andere Frage.

Ist gar nicht so viel Arbeit. Bibliothek einbinden, DEBUG definieren, fertig.

Jörg Reinholz

[ChrisB]

Hi,

Ich fände es äußerst sinnvoll, wenn man das Standardverhalten, bei einer fehleneden Konstantedefinition einfach deren Bezeichner als String anzunehmen, abschalten könnte,

Nein, das ist nicht möglich.

Ist es doch.

Du widersprichst mir also, nur um dann das vorzuschlagen, was ich nachfolgend schon als – indirekte – Möglichkeit genannt habe …

Mit einem eigenen Error-Handler würde das vermutlich gehen – ob’s den Aufwand wert ist, ist eine andere Frage.

Ist gar nicht so viel Arbeit.

Ich sprach nicht von Arbeit, sondern von Aufwand – u.a. dem, den das für den PHP-Interpreter bedeutet. Ob es sich lohnt, für das bisschen Ergebnis (das man mit vernünftig eingestelltem error reporting und logging auch haben könnte, nur vielleicht nicht absolut in „Echtzeit“) ggf. Performance durch einen eigenen error handler zu verschwenden, halte ich für fragwürdig.

[http://www.tyrael.hu/2011/06/26/performance-of-error-handling-in-php/: “if you have an error and a custom error handler which gets executed, that yields for a ~10X performance loss”]

MfG ChrisB

[dedlfix]

Tach!

Mit einem eigenen Error-Handler würde das vermutlich gehen – ob’s den Aufwand wert ist, ist eine andere Frage.
Ist gar nicht so viel Arbeit.
Ich sprach nicht von Arbeit, sondern von Aufwand – u.a. dem, den das für den PHP-Interpreter bedeutet.

Den für den PHP-Interpreter kann man vernachlässigen. Es geht im vorliegenden Fall darum, Tippfehler zu erkennen, also in der Debug-Phase tätig zu werden.

Performance durch einen eigenen error handler zu verschwenden, halte ich für fragwürdig.

Aber nur, wenn man unordentlich programmiert und alle naselang der Handler für ansonsten vermeidbare Konstrukte aufgerufen wird. Wird der hingegen selten und bei einem echten Fehler aufgerufen, dann ist es völlig verschmerzbar, ob der Anwender nun Millisekunden später oder performant nicht zu seinem Ziel kommt.

dedlfix.

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

Performance durch einen eigenen error handler zu verschwenden, halte ich für fragwürdig.

Aber nur, wenn man unordentlich programmiert und alle naselang der Handler für ansonsten vermeidbare Konstrukte aufgerufen wird. Wird der hingegen selten und bei einem echten Fehler aufgerufen, dann ist es völlig verschmerzbar, ob der Anwender nun Millisekunden später oder performant nicht zu seinem Ziel kommt.

Um das nochmal klrazustellen:

Mir ging es darum, nicht definierte Konstanten erkennen zu können.

Die Konstanten regeln oft das Laufzeitverhalten und liegen daher im Verantwortungsbreich des Admins oder manchmal sogar des Modulbetreuers oder (über ein Interface) des Users. Der kann also aus der zugehörigen INI leicht eine Zeile rauslöschen oder ungültig machen, ohne dass es weiter auffällt, bzw. es könnte ein Updatefehler der INI-Datei vorkommen.

Bisher regele ich das immer so, dass das Ladeprogramm für die INI alle Konstanten kennt, die erwartet werden. Das prüft also bei jedem Request, ob alle Konstanten vorhanden sind. Das findet natürlich auf Script-Ebene statt.  Ich denke, dass das mehr Kraft kostet, als wenn PHP originär eine Möglichkeit zum Konstantencheck eingebaut hätte.

Außerdem ist das so ziemlicher Programmieraufwand.

Spirituelle Grüße
Euer Robert

[dedlfix]

Tach!

Mir ging es darum, nicht definierte Konstanten erkennen zu können.

Soweit dachte ich mir das auch.

Die Konstanten regeln oft das Laufzeitverhalten und liegen daher im Verantwortungsbreich des Admins oder manchmal sogar des Modulbetreuers oder (über ein Interface) des Users. Der kann also aus der zugehörigen INI leicht eine Zeile rauslöschen oder ungültig machen, ohne dass es weiter auffällt, bzw. es könnte ein Updatefehler der INI-Datei vorkommen.

Ok, in dem Fall muss man mit einem Nichtvorhandensein rechnen.

Bisher regele ich das immer so, dass das Ladeprogramm für die INI alle Konstanten kennt, die erwartet werden. Das prüft also bei jedem Request, ob alle Konstanten vorhanden sind. Das findet natürlich auf Script-Ebene statt.  Ich denke, dass das mehr Kraft kostet, als wenn PHP originär eine Möglichkeit zum Konstantencheck eingebaut hätte.

Und was genau soll es in dem Fall eines Fehlens tun? Das ist ja dann nicht mehr nur zur Entwicklungszeit sondern während des produktiven Einsatzes. In dem Fall finde ich eine Fehlermeldung nicht direkt erstrebenswert. Zumal dann ja auch die Meldungen unsichtbar geschaltet sein sollten.

Außerdem ist das so ziemlicher Programmieraufwand.

Nicht wirklich.

defined('KONSTANTE') || define('KONSTANTE', 'defaultwert');

dedlfix.

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Außerdem ist das so ziemlicher Programmieraufwand.

Nicht wirklich.

defined('KONSTANTE') || define('KONSTANTE', 'defaultwert');

Das ist eine gute Idee. Wenn nicht individuell festgelegt, dann eben Standardwert.

Das werde ich in meiner Lib mal generell so umbauen. Sind inzwischen so an die 170 Konstanten und täglich kommen Wünsche dazu. Wenn man mit der Konfigurierbarkeit erstmal anfängt, dann wächst das schnell weiter :-O

Spirituelle Grüße
Euer Robert

[Jörg Reinholz]

Du widersprichst mir also, nur um dann das vorzuschlagen, was ich nachfolgend schon als – indirekte – Möglichkeit genannt habe …

Naja. Wie soll ich es sagen ... ich wollte keineswegs unhöflich oder verletzend formulieren, habe Dich aber zitiert und musste mich ergo eng an Deine Formulierung gehalten. Da stand zunächst es gehe nicht und erst weiter unten hast Du dann den, dem dieser Deiner vorherigen Behauptung widersprechenden Lösungsansatz selbst genannt.

Du hast jetzt von einer Webseite zitiert:

“if you have an error and a custom error handler which gets executed, that yields for a ~10X performance loss”

Das sehe ich als Aussage kritisch. Zu erst einmal muss man dedlfix folgen, der richtig aussagt, dass es egal sei dass man einen höheren Aufwand habe, wenn man so zum korrekten Ergebnis kommt. Der Bagger fährt ja auch erst zur Baustelle statt das Loch gleich im Hof des Bauunternehmens auszuheben...

Ich habe das mal gemessen.

Versuchsreihe A - PHP (als CGI) auf der Linux-Konsole:

Datei fehler0.php:

<html><style type="text/css"><script type="text/javascript>"  
<?php  
require_once '[link:http://www.fastix.org/r/use_strict.txt@title=use_strict.php]';  
$str.=$var;  
#R4  
#R5  
#R6  
#R7  
$foo='foo';  
#include 'not.existent.file';  
$bar=4/0;  
?>  
<p>(Not) Fine!</p>  
</html>

Aufruf_ time php fehler0.php

real    0m0.042s  
user    0m0.020s  
sys     0m0.023s

fehler0_ohne_use_strict.php:

<html><style type="text/css"><script type="text/javascript>"
<?php
#DEFINE('DEBUG', 0); require_once 'use_strict.php';
#R4
#R5
#R6
#R7
$foo=foo;
include 'not.existent.file';
$bar=0;
if (0==$bar) { trigger_error('$baz ist 0! Durch 0 kann nicht dividiert werden.', E_USER_ERROR); }
$bar=4/$bar;
?>
<p>(Not) Fine! The Script was NOT breaked.</p>
</html>

Aufruf: php fehler0_ohne_use_strict.php:

real    0m0.038s  
user    0m0.025s  
sys     0m0.016s

Ich habe das mehrfach getestet. Die Werte haben sich nicht signifikant unterschieden. Insbesondere waren in einigen - aber definitiv der Minderheit - der Versuche die Aufrufe mit der Fehlerbehandlung sogar schneller, was hier der Unvollkommenheit der Testumgebung zuzuschreiben ist. Fakt ist aber, dass meine Messung dennoch der Aussage eines 10-fachen Performance-Verlustes widerspricht, denn dann hätte das Skript mit "use-strict" deutlich mehr Zeit verbrauchen müssen.

Jörg Reinholz

[Robert R.]

Liebe Mitdenker,
liebe Wissende,
liebe Neugierige,

ja!

Ich fände es äußerst sinnvoll, wenn man das Standardverhalten, bei einer fehleneden Konstantedefinition einfach deren Bezeichner als String anzunehmen, abschalten könnte,

Nein, das ist nicht möglich.

Ist es doch. Man kann PHP ein Verhalten wie bei "use strict" (Perl) bzw. "option explicit" (VBA) beibringen.

Mit einem eigenen Error-Handler würde das vermutlich gehen – ob’s den Aufwand wert ist, ist eine andere Frage.

Ist gar nicht so viel Arbeit. Bibliothek einbinden, DEBUG definieren, fertig.

Interessante Idee. Muss ich mich näher mit beschäftigen. Danke.

Spirituelle Grüße
Euer Robert

[Camping_RIDER]

Aloha ;)

Ich fände es äußerst sinnvoll, wenn man das Standardverhalten, bei einer fehleneden Konstantedefinition einfach deren Bezeichner als String anzunehmen, abschalten könnte, Besser würde mir noch gefallen, wenn man sogar festlegen könnte, ob es eine Notice (Verhalten wie bisher?), eine Warnung oder einen Fehler mit Abbruch geben soll.

Schätzungsweise nicht. Mir wäre nichts bekannt (was zugegebenermaßen nichts heisen muss). Dazu folgendes Zitat:

When it doesn't find such a constant, PHP (bizarrely) interprets it as a string ('department', etc).
It's not "bizarre"... It's "backward compatible". PHP originally allowed and even promoted using unquoted strings as keys. (Okay, maybe it is still "bizarre". :-)

[Quelle]

Was das zweite angeht: Ich bin sicher, dass du das Verhalten des PHP-Compilers im Fehlerfall nicht fehlerspezifisch beeinflussen kannst. Das wäre auch definitiv nicht Sinn der Sache.

Grüße,

RIDER

[dedlfix]

Tach!

Kann man bei PHP das Verhalten bei fehlenden Konstanten eigentlich irgendwo festlegen?

Dazu ist mir nichts bekannt.

Ich fände es äußerst sinnvoll, wenn man das Standardverhalten, bei einer fehleneden Konstantedefinition einfach deren Bezeichner als String anzunehmen, abschalten könnte, Besser würde mir noch gefallen, wenn man sogar festlegen könnte, ob es eine Notice (Verhalten wie bisher?), eine Warnung oder einen Fehler mit Abbruch geben soll.

PHP-IDEs, die nicht nur die generelle PHP-Syntax kennen, sondern den Code beim Verfassen gleich mit analysieren, können üblicherweise eingestellt werden, wie schwer ein erkanntes potentielles Problem gemeldet werden soll. Damit bekommst du es schon beim Tippen präsentiert und nicht erst zur Laufzeit.

Dein eigentliches Problem ist doch, undefinierte Konstanten zu erkennen. PHP zwingen zu wollen, deswegen zu schreien, ist eine Möglichkeit, aber meiner Meinung nach nicht die beste. Das zeigt den Fehler indirekt und auch nur, wenn du mehr oder weniger zufällig den Programmabschnitt testest. PHP-IDEs (ich mag ja PHPStorm) zeigen Probleme direkt auf. Und nicht nur das mit den Konstanten sondern auch noch einige andere potentielle Fallstricke, die für PHP wie gültige Syntax aussehen.

dedlfix.