PHP konfigurieren

[Rob 393]

Hallo,

ich mache gerade meine ersten Schritte in PHP. Mich stört dieses Konzept der Notices und Warnings. Kann man den PHP-Interpreter irgendwie so konfigurieren, dass er das Programm abbricht, wenn er eine Notice schmeißen würde. Also so, wie sich andere (,zumindest mir alle bekannten) Programmiersprachen verhalten?

Eingabe:

  
$t = 2;  
print_r($x);  
print_r($t);  
  

Ausgabe  
PHP Notice:  Undefined variable: x in php shell code on line 1  
2

Das hat mich schon seeehr erstaunt... noch mehr erstaunt hat mich dies hier:

Eingabe:

  
if(test) echo "test existiert";  

Ausgabe:

PHP Notice:  Use of undefined constant test - assumed 'test' in php shell code on line 1  
test existiert

Das finde ich ja schon grob fahrlässig. Dieses Verhalten möchte ich also nicht. Ich möchte, dass der PHP-Interpreter bei bei einer notice oder warning aussteigt und nicht irgendwass "assumed". Geht das irgendwie?

[dedlfix]

Tach!

Mich stört dieses Konzept der Notices und Warnings. Kann man den PHP-Interpreter irgendwie so konfigurieren, dass er das Programm abbricht, wenn er eine Notice schmeißen würde.

Eine Notice ist nur ein Hinweis, und im Prinzip nichts, was den Ablauf wesentlich beeinträchtigt - theoretisch jedenfalls. Andererseits ist eine Notice ein Hinweis auf ein mögliches Problem. Manche Warnings kann amn auch nicht abstellen, selbst wenn man die Ursache in seinem Code beachtet und entsprechende Maßnahmen ergreift. Hier wäre ein ständiger Abbruch kontraproduktiv.

Das finde ich ja schon grob fahrlässig. Dieses Verhalten möchte ich also nicht. Ich möchte, dass der PHP-Interpreter bei bei einer notice oder warning aussteigt und nicht irgendwass "assumed". Geht das irgendwie?

Definier dir einen eigenen Error-Handler, da kannst du auch das Programm abbrechen, wenn du das magst. Bewusst ignorierte Meldungen kann man dabei auch ausschließen, indem man ihnen im Code ein @ voranstellt und im Error-Handler fragt, ob error_reporting() 0 liefert. Mehr dazu im Kapitel zum Error Handling.

dedlfix.

[Rob 393]

hi,

Mich stört dieses Konzept der Notices und Warnings. Kann man den PHP-Interpreter irgendwie so konfigurieren, dass er das Programm abbricht, wenn er eine Notice schmeißen würde.

Eine Notice ist nur ein Hinweis, und im Prinzip nichts, was den Ablauf wesentlich beeinträchtigt - theoretisch jedenfalls. Andererseits ist eine Notice ein Hinweis auf ein mögliches Problem. Manche Warnings kann amn auch nicht abstellen, selbst wenn man die Ursache in seinem Code beachtet und entsprechende Maßnahmen ergreift. Hier wäre ein ständiger Abbruch kontraproduktiv.

  
if(test) echo "test existiert";  

ich kann beim besten Willen nicht nachvollziehen, warum dieser Ausdruck wahr sein sollte.. aber gut. Ich muss das Konzept verstehen.

Das finde ich ja schon grob fahrlässig. Dieses Verhalten möchte ich also nicht. Ich möchte, dass der PHP-Interpreter bei bei einer notice oder warning aussteigt und nicht irgendwass "assumed". Geht das irgendwie?

Definier dir einen eigenen Error-Handler, da kannst du auch das Programm abbrechen, wenn du das magst. Bewusst ignorierte Meldungen kann man dabei auch ausschließen, indem man ihnen im Code ein @ voranstellt und im Error-Handler fragt, ob error_reporting() 0 liefert. Mehr dazu im Kapitel zum Error Handling.

Das ist gut, danke. Ich werde jetzt erstmal mein Programm abbrechen lassen, wenn es nicht sauber durchläuft.

http://www.php.net/manual/en/function.set-error-handler.php

[Matthias Apsel]

Om nah hoo pez nyeetz, Rob 393!

if(test) echo "test existiert";

> ich kann beim besten Willen nicht nachvollziehen, warum dieser Ausdruck wahr sein sollte.. aber gut. Ich muss das Konzept verstehen.  
  
`if ($test)`{:.language-php} ist äquivalent zu `if ($test != "")`{:.language-php}. Du möchtest  
~~~php
if (isset(test)) echo "test existiert";  

Matthias

[Jörg Reinholz]

Moin!

if ($test) ist äquivalent zu if ($test != ""). Du möchtest

if (isset(test)) echo "test existiert";

  
Ich erlaube mir die Frechheit und korrigiere mal den Typo:  
  
~~~php
if (isset($test)) echo "test existiert";  

Jörg Reinholz

[Rob 393]

Hallo,

if(test) echo "test existiert";

> > ich kann beim besten Willen nicht nachvollziehen, warum dieser Ausdruck wahr sein sollte.. aber gut. Ich muss das Konzept verstehen.  
>   
> `if ($test)`{:.language-php} ist äquivalent zu `if ($test != "")`{:.language-php}. Du möchtest  
> ~~~php

if (isset(test)) echo "test existiert";  

> 

Ich kann dir nicht folgen. test (ohne Dollar) ist nicht deklariert. test existiert nicht. if(test) kann deshalb meines Erachtens nicht wahr sein.  Es geht um den Fall, dass der Entwickler vor der Variable test das bei PHP nötige $ vergessen hat. Ich finde das keinen ungewöhnlichen Eingabefehler, zumindest für Leute, die von anderen Sprachen kommen. Nochmal konkreter

Eingabe:

  
$test = null;  
if(test) echo "test existiert";  

Ausgabe:

  
PHP Notice:  Use of undefined constant test - assumed 'test' in php shell code on line 1  
test existiert  

Aber egal, ich verstehe das Konzept jetzt.

[Der Martin]

Hi,

if(test) echo "test existiert";
ich kann beim besten Willen nicht nachvollziehen, warum dieser Ausdruck wahr sein sollte.. aber gut. Ich muss das Konzept verstehen.

Ein Bezeichner ohne Dollarzeichen davor und ohne Funktionsklammer hintendran wird als Konstante betrachtet. Konstanten kann man mit define() definieren - wer hätte das gedacht?

Ich kann dir nicht folgen. test (ohne Dollar) ist nicht deklariert. test existiert nicht. if(test) kann deshalb meines Erachtens nicht wahr sein.

Doch, denn hier greift eine Pseudo-Intelligenz von PHP ein, die sich auch in der Notice ausdrückt:

PHP Notice:  Use of undefined constant test - assumed 'test' in php shell code on line 1

PHP stellt fest, dass die benannte Konstante test nicht existiert und nimmt deshalb an, du hättest stattdessen den String 'test' gemeint. Nach der internen Fehlerkorrektur lautet der Ausdruck also if ('text'), und der ergibt true. Das muss man nicht gut finden, aber wohl akzeptieren.

Es geht um den Fall, dass der Entwickler vor der Variable test das bei PHP nötige $ vergessen hat. Ich finde das keinen ungewöhnlichen Eingabefehler, zumindest für Leute, die von anderen Sprachen kommen.

Völlig richtig, deswegen sollte man solche Notices auch ernst nehmen und sie während der Entwicklungs- und Testphase auch immer anzeigen lassen.

Aber egal, ich verstehe das Konzept jetzt.

Wirklich? ;-)

Ciao,
 Martin

[Tom]

Hello,

PHP stellt fest, dass die benannte Konstante test nicht existiert und nimmt deshalb an, du hättest stattdessen den String 'test' gemeint. Nach der internen Fehlerkorrektur lautet der Ausdruck also if ('text'), und der ergibt true. Das muss man nicht gut finden, aber wohl akzeptieren.

Es geht um den Fall, dass der Entwickler vor der Variable test das bei PHP nötige $ vergessen hat. Ich finde das keinen ungewöhnlichen Eingabefehler, zumindest für Leute, die von anderen Sprachen kommen.

Völlig richtig, deswegen sollte man solche Notices auch ernst nehmen und sie während der Entwicklungs- und Testphase auch immer anzeigen lassen.

Deswegen sollte man in PHP boolesche Abfragen, von denen das Leben (des Servers) abhängt auch grundsätzlich als Äquivalenzabfragen ausführen

  
if (test === true)  
{  
    echo "test exisistert";  
}  
else  
{  
    echo "Ey you proggiman! Are you foolish?";  
}  
  

ergibt dann

  
Notice: Use of undefined constant test - assumed 'test' in M:\USER\TOM\WebProgTests\Xampp\variables\types.php on line 22  
Ey you proggiman! Are you foolish?  

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Völlig richtig, deswegen sollte man solche Notices auch ernst nehmen und sie während der Entwicklungs- und Testphase auch immer anzeigen lassen.
Deswegen sollte man in PHP boolesche Abfragen, von denen das Leben (des Servers) abhängt auch grundsätzlich als Äquivalenzabfragen ausführen

Wozu muss ich das im weiteren Leben des Script mit mir rumschleppen, wenn ich die Ursache behoben habe? Wenn du schon Mehraufwand haben möchtest, dann steck das doch in (Unit-)Tests.

dedlfix.

[Jörg Reinholz]

PHP stellt fest, dass die benannte Konstante test nicht existiert und nimmt deshalb an, du hättest stattdessen den String 'test' gemeint. Nach der internen Fehlerkorrektur lautet der Ausdruck also if ('text'), und der ergibt true. Das muss man nicht gut finden, aber wohl akzeptieren.

Naja. Man kann da was "veranstalten" und im Fall einer Notiz/Warnung abbrechen:

<?php  
function errHandle($errNo, $errStr, $errFile, $errLine) {  
    $msg = "$errStr in $errFile on line $errLine";  
    if ($errNo == E_NOTICE || $errNo == E_WARNING) {  
        throw new ErrorException($msg, $errNo);  
    } else {  
        echo $msg;  
    }  
}  
  
set_error_handler('errHandle');  
  
if (foo) { echo foo; }  
echo "Das darf nicht mehr ausgegeben werden.";  
?>

Perl verhält sich übrigens ähnlich:

#!/usr/bin/perl -W  
#use strict;  
if (test) { print STDOUT wahr, "\r\n" };  
  
print "Das soll nicht mehr ausgegeben werden.", "\r\n";  

Noch grausamer wird es (weil keine Warnung erfolgt), wenn man das -w oder -W in der shebang vergisst. Aber von daher kommt wohl das Verhalten in PHP. Allerdings kann man in Perl dann immer noch ein einfaches use strict verwenden (oben das Kommentarzeichen entfernen) um ein brauchbares, fehlerintolerantes  Verhalten zu erzwingen.

In PHP kann man das nachbauen, in dem man den Teil:

<?php  
function errHandle($errNo, $errStr, $errFile, $errLine) {  
    $msg = "$errStr in $errFile on line $errLine";  
    if ($errNo == E_NOTICE || $errNo == E_WARNING) {  
        throw new ErrorException($msg, $errNo);  
    } else {  
        echo $msg;  
    }  
}  
set_error_handler('errHandle');  

z.B. nach /foo/bar/use_strict.php schreibt (am besten ohne schließendes '?>'!) und dann so verwendet:

<?php  
require '/foo/bar/use_strict.php';  
  
if (foo) { echo foo; }  
echo "Das soll nicht mehr ausgegeben werden.";  
?>

Jörg Reinholz

[dedlfix]

Tach!

<?php

function errHandle($errNo, $errStr, $errFile, $errLine) {
    $msg = "$errStr in $errFile on line $errLine";
    if ($errNo == E_NOTICE || $errNo == E_WARNING) {
        throw new ErrorException($msg, $errNo);
    } else {
        echo $msg;
    }
}
set_error_handler('errHandle');

  
Da man die Funktion errHandle in aller Regel für nichts anderes als das Übergeben an die Funktion set\_error\_handler() verwendet, kann man sie gleich als anonyme Funktion notieren. Das sähe dann so aus:  
  
set\_error\_handler(function ($errNo, $errStr, $errFile, $errLine) {  
  ...  
});  
  
Weiterhin würde ich für den angestrebten Fall des OP wohl keine Exception werfen, sondern gleich abbrechen.  
  
Allerdings könnte man dieses Konstrukt auch als Übersetzer von herkömmlichen Meldungen in Exceptions verwenden. Dagegen spricht allerdings, dass die Eigenschaften file und line nicht gesetzt werden können. Sie enthalten immer die Daten der throw-Zeile, und sind damit nicht sinnvoll gefüllt. Das stellt nicht unbedingt ein Problem dar, wenn es nur darum geht, sie mit try-catch fangen zu können.  
  
  
dedlfix.

[Jörg Reinholz]

Moin!

Weiterhin würde ich für den angestrebten Fall des OP wohl keine Exception werfen, sondern gleich abbrechen.

Wie auch immer. Ich habe das mal realisiert und öffentlich zugänglich gemacht, damit die Skriptkiddies auch was davon haben: PHP mit use strict bzw. option explicit.

Habe das so programmiert, dass es über eine Zeile einfügbar ist (in Perl bzw. VB gehts ja auch mit einer Zeile) und dass es über eine Konstante steuerbar ist. Vorschläge, Ver(schlimm)besserungen und Diskussionsbeiträge sind willkommen.

Jörg Reinholz

[tami]

hi Matthias,

if ($test) ist äquivalent zu if ($test != ""). D

Das ist eigentlich nicht ganz korrekt. Der Inhalt von $test wird zu einer boolschen Variable gecastet:

When converting to boolean, the following values are considered FALSE:
 the boolean FALSE itself
 the integer 0 (zero)
 the float 0.0 (zero)
 the empty string, and the string "0"
 an array with zero elements
 an object with zero member variables (PHP 4 only)
 the special type NULL (including unset variables)
SimpleXML objects created from empty tags

$test != "" ist in dem Sinne noch irreführender, weil da $test wiederum gecastet wird, weil es "!=" statt "!==" ist.

Aus meiner Sicht macht "!=" in Javascript (s. Crockford) wie auch in PHP keinen Sinn. (s.a. http://forum.de.selfhtml.org/archiv/2013/10/t215185/#m1474005).

mfg

tami

[Tom]

Hello,

Das ist gut, danke. Ich werde jetzt erstmal mein Programm abbrechen lassen, wenn es nicht sauber durchläuft.

Das ist aber bei behandelbaren Laufzeitfehlern dusselig. Die setzt man doch gerade erst dafür ein, um den Steuerfluss beeinflussen zu können. Dafür muss man die Fehlerquellen kennen und die Fehler entsprechend abfangen.

Du meinst vermutlich Programmierfehler. Die musst Du natürlich durch sauberes Arbeiten vermeiden oder möglichst schnell beseitigigen. Dass die Ausgabe der Fehlermeldung auf der Standardausgabe stattfindet, ist eigentlich nur eine "Maßnahme für kleine Systeme". Nicht Jeder hat zwei Bildschirme, und einen Server, auf dem man z.B. "tail -f error.log" laufen lassen kann, neben seinem Arbeitsplatz stehen.

Das ist aber, angesichts der vielen Frameworks, ganz praktisch, wenn man die Fehlermeldung nicht mitten zweischen die bunten Bilder reinschreiben lässt. Da geht sie allzu schnell unter. Und bei Sekundärrequests versickert sie oft im Browser (Quelltext ansehen?) ...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Rob 393]

hi,

Das ist gut, danke. Ich werde jetzt erstmal mein Programm abbrechen lassen, wenn es nicht sauber durchläuft.

Das ist aber bei behandelbaren Laufzeitfehlern dusselig. Die setzt man doch gerade erst dafür ein, um den Steuerfluss beeinflussen zu können. Dafür muss man die Fehlerquellen kennen und die Fehler entsprechend abfangen.

ja, das ist schon klar. Fehler, die während der Laufzeit behandelt werden können, führen natürlich nicht zum Abbruch. Das wäre ja gegen jegliches Programmierparadigma.

Du meinst vermutlich Programmierfehler. Die musst Du natürlich durch sauberes Arbeiten vermeiden oder möglichst schnell beseitigigen. Dass die Ausgabe der Fehlermeldung auf der Standardausgabe stattfindet, ist eigentlich nur eine "Maßnahme für kleine Systeme". Nicht Jeder hat zwei Bildschirme, und einen Server, auf dem man z.B. "tail -f error.log" laufen lassen kann, neben seinem Arbeitsplatz stehen.

du meinst das apache error log? Eigentlich will ich die Errorausgaben ausschließlich in diesem Log sehen, genau. Im Browser tue ich mich etwas schwer.

[Tom]

Hello,

ja, das ist schon klar. Fehler, die während der Laufzeit behandelt werden können, führen natürlich nicht zum Abbruch. Das wäre ja gegen jegliches Programmierparadigma.

Tun sie aber, wenn Du die automatische behandlung nicht unterdrückst.
Und dann solltest Du sie tunlichst auch selber behandeln.
Wenn also z.B. ein file_open($blah, 'rb+') schief geht, könnte es verschiedene Ursachen haben:
* Datei existiert noch nicht
* Öffnen generell nicht möglich wegen fehlender Rechte
* Datei ist scheibgeschützt
* Netzwerkfehler
* ...

Ich hatte da schon mehrfach einen  Anlauf genommen, die textuellen Fehlermeldungen von PHP wieder in eindeutige Fehlernummern zurückzuübersetzen. Das ist eine "Zweimanjahresaufgabe".

Das letzte Mal
https://forum.selfhtml.org/?t=217385&m=1493059

Aber die Resonanz für Mithilfe ist nicht sehr groß.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Wenn also z.B. ein file_open($blah, 'rb+') schief geht, könnte es verschiedene Ursachen haben:
* Datei existiert noch nicht
* Öffnen generell nicht möglich wegen fehlender Rechte
* Datei ist scheibgeschützt
* Netzwerkfehler

Die letzten drei sind alles keine Ursachen, die das PHP-Script beheben kann. Beim ersten ist es ein vermeidbarer Programmierfehler.

Ich hatte da schon mehrfach einen  Anlauf genommen, die textuellen Fehlermeldungen von PHP wieder in eindeutige Fehlernummern zurückzuübersetzen.

Deswegen sehe ich das auch nicht als sinnvoll an, dass das PHP-Script bis ins Detail weiß, was da kaputt ist. Es kann es nicht reparieren.

dedlfix.

[Tom]

Hello,

Wenn also z.B. ein file_open($blah, 'rb+') schief geht, könnte es verschiedene Ursachen haben:
* Datei existiert noch nicht
* Öffnen generell nicht möglich wegen fehlender Rechte
* Datei ist scheibgeschützt
* Netzwerkfehler

Die letzten drei sind alles keine Ursachen, die das PHP-Script beheben kann. Beim ersten ist es ein vermeidbarer Programmierfehler.

Es geht bei der Fehlerbehandlung nicht immer um Ursachenbehebung, sondern um Behandlung des Fehlers. Und User eine sinnvolle Antwort zu geben, gehört für mich dazu.

Du bist aber schon noch der Originl Dedlfix?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Es geht bei der Fehlerbehandlung nicht immer um Ursachenbehebung, sondern um Behandlung des Fehlers. Und User eine sinnvolle Antwort zu geben, gehört für mich dazu.

Ausführliche technische Details sind aus meiner Sicht für den Nutzer keine sinnvolle Information. Er kann damit nichts anfangen oder gar die Ursache beheben. - Eine Aktion ist schiefgelaufen und kann nicht sofort repariert werden. Für den Fall muss eine Alternative gefunden werden. Wenn du dazu die haargenaue Ursache brauchst, denke ich, dass du dich viel zu sehr verzettelst. Gib dem Administrator die Möglichkeit, den Meldungstext nachzulesen und dem Anwender eine Umleitung.

dedlfix.

[Tom]

Hello,

Es geht bei der Fehlerbehandlung nicht immer um Ursachenbehebung, sondern um Behandlung des Fehlers. Und User eine sinnvolle Antwort zu geben, gehört für mich dazu.

Ausführliche technische Details sind aus meiner Sicht für den Nutzer keine sinnvolle Information. Er kann damit nichts anfangen oder gar die Ursache beheben.

Es sprach ja auch keiner davon, die Fehlermeldung an den Client weiterzuleiten.
Ich sprach von "Behandlung des Fehlers". Dazu gehört für mich, dass ich eine passende Aktion für den User daraus ableite.

Eine Aktion ist schiefgelaufen und kann nicht sofort repariert werden. Für den Fall muss eine Alternative gefunden werden. Wenn du dazu die haargenaue Ursache brauchst, denke ich, dass du dich viel zu sehr verzettelst. Gib dem Administrator die Möglichkeit, den Meldungstext nachzulesen und dem Anwender eine Umleitung.

Was soll der Adminstrator damit behelligt werden, wenn ein Programm einen von mehreren vorhersehbaren Zustände einnimmt, der aber leider gerade nicht der vom User erwünschte war?

Er kann jetzt - vernünftig informiert - eine Alternative wählen, warten, es nochmal versuchen oder aufgeben...

Wie behandelst Du im Änderungsvorgang für einen Datensatz den Fall, dass ein anderer User mit seiner Änderung schneller war?

Einfach unter den Tisch fallen lassen? *pfui!*

Aber ich sage Dir, wie die meisten Webanwendungen den behandeln: gar nicht!
Und das ist richtig böse.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Was soll der Adminstrator damit behelligt werden, wenn ein Programm einen von mehreren vorhersehbaren Zustände einnimmt, der aber leider gerade nicht der vom User erwünschte war?

Da fällt mir grad kein Anwendungsfall ein, bei dem eine PHP-Fehlermeldung zwingend zu dessen Erkennung notwendig ist. Da würde ich meine Energie im konkreten Fall in eine Suche nach alternativen Erkennungsmöglichkeiten stecken.

Wie behandelst Du im Änderungsvorgang für einen Datensatz den Fall, dass ein anderer User mit seiner Änderung schneller war?

Das ist kein Fall, für den ich eine PHP-Fehlermeldung auswerten muss. Auch ist das keine Datenbankfehlermeldung, wenn du nicht gerade in einen Unique-Contraint oder sowas rennst. Dazu gäbe es jedenfalls eindeutige Fehlermeldungen mit Nummer. In aller Regel wird dieser Fall jedoch anhand eines Prüffeldinhalts festgemacht. Das ist kein Anwendungsfall für dein Vorhaben.

dedlfix.

[Jörg Reinholz]

Moin Tom.

Ich hatte da schon mehrfach einen  Anlauf genommen, die textuellen Fehlermeldungen von PHP wieder in eindeutige Fehlernummern zurückzuübersetzen. Das ist eine "Zweimanjahresaufgabe".

Das letzte Mal
https://forum.selfhtml.org/?t=217385&m=1493059

Aber die Resonanz für Mithilfe ist nicht sehr groß.

Nun. Ich denke hier das Thema zu hoch (genauer: zu tief) gesteckt. Womöglich solltest Du mit derlei Ansinnen irgendwo bei php.net fündig werden. Ich habe hier mal zwei Links für Dich:

http://stackoverflow.com/questions/2355164/list-of-all-the-possible-php-errors

http://www.php.net/manual/en/errorfunc.constants.php

Jörg Reinholz

[dedlfix]

Tach!

if(test) echo "test existiert";

> ich kann beim besten Willen nicht nachvollziehen, warum dieser Ausdruck wahr sein sollte.. aber gut. Ich muss das Konzept verstehen.  
  
Diesen Willen solltest du aber aufbringen, wenn du eine Programmiersprache einsetzen möchtest oder musst. Es ist einfacher, mit den Gegebenheiten eines Systems eine Lösung zu finden, als gegen es zu arbeiten.  
  
Das PHP-Konzept sieht hier vor, dass der Anfänger vermutlich nur die Anführungszeichen vergessen hat und das wohl ein String sein soll. So sagt es ja auch die Meldung: Use of undefined constant test - assumed 'test'. Dieser String evaluiert im booleschen Kontext zu true, und damit ist die Bedingung erfüllt.  
  
Diese Automatismen sollte man kennen, damit man nicht darüber stolpert. Im Wesentlichen ist es die automatische Typumwandlung. Was kommt raus, wenn bestimmte Werte (zum Beispiel Strings) in booleschen oder numerischen Kontext gebracht werden? Diese Umwandlung erfolgt stillschweigend. Dazu gibt es eine Tabelle im Manual-Anhang [PHP type comparison tables](http://www.php.net/manual/en/types.comparisons.php).  
  
  
dedlfix.

[Rob 393]

Tach!

if(test) echo "test existiert";

> > ich kann beim besten Willen nicht nachvollziehen, warum dieser Ausdruck wahr sein sollte.. aber gut. Ich muss das Konzept verstehen.  
  

> Das PHP-Konzept sieht hier vor, dass der Anfänger vermutlich nur die Anführungszeichen vergessen hat und das wohl ein String sein soll. So sagt es ja auch die Meldung: Use of undefined constant test - assumed 'test'. Dieser String evaluiert im booleschen Kontext zu true, und damit ist die Bedingung erfüllt.  
  
Danke für die Erklärung. Dann ist das im Grunde klar. Das Ducktypingkonzept kenne ich, das ist nicht das Problem.  
  
So, jetzt mal ein bisschen php-gecodet und bald zurück in diesem Forum für einen Berg dummer Fragen!  
  
rob  

[Tom]

Hello,

Tach!

if(test) echo "test existiert";

> > > ich kann beim besten Willen nicht nachvollziehen, warum dieser Ausdruck wahr sein sollte.. aber gut. Ich muss das Konzept verstehen.  
>   
> > Das PHP-Konzept sieht hier vor, dass der Anfänger vermutlich nur die Anführungszeichen vergessen hat und das wohl ein String sein soll. So sagt es ja auch die Meldung: Use of undefined constant test - assumed 'test'. Dieser String evaluiert im booleschen Kontext zu true, und damit ist die Bedingung erfüllt.  
>   
> Danke für die Erklärung. Dann ist das im Grunde klar. Das Ducktypingkonzept kenne ich, das ist nicht das Problem.  
>   
> So, jetzt mal ein bisschen php-gecodet und bald zurück in diesem Forum für einen Berg dummer Fragen!  
  
~~~php
  
SelfForum Notice:  Use of undefined expression 'dummer Fragen'  
- assumed 'lazy behavior, not used yet a search engine' in chapter above.  
Answers will turn out bad!  
  

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Also so, wie sich andere (,zumindest mir alle bekannten) Programmiersprachen verhalten?

Welche wären das?

Das finde ich ja schon grob fahrlässig.

Also wenn bei deinem Auto die Warnleuchte kommt, dass das Scheibenwaschwasser zu wenig ist, soll sofort der Motor ausgehen und nicht mehr anspringen?

Ansonsten hast du ja den Tip bekommen, einen eigenen error-handler zu definieren. Und viel Spass dabei, dein Script unter jedem Betriebessystem unter jeder PHP-Version zu testen. Denn nur weil es bei dir keine Notices und Warnings gibt, heisst es nicht, dass es überall so ist.
Aus dem Grund bricht ein Script bei sowas ja auch nicht ab.

[Rob 393]

Hi,

Also so, wie sich andere (,zumindest mir alle bekannten) Programmiersprachen verhalten?

Welche wären das?

C, Java, Python, Erlang, Eiffel, Fortran um mal die zu nennen, mit denen ich produktiv gearbeitet habe.

Das finde ich ja schon grob fahrlässig.

Also wenn bei deinem Auto die Warnleuchte kommt, dass das Scheibenwaschwasser zu wenig ist, soll sofort der Motor ausgehen und nicht mehr anspringen?

Dieser Vergleich hinkt schon nicht mal mehr. Wenn bei meinem Auto der Motor fehlt, es aber trotzdem fährt, hätte ich schon gerne, dass es stoppt, ja.

Ansonsten hast du ja den Tip bekommen, einen eigenen error-handler zu definieren. Und viel Spass dabei, dein Script unter jedem Betriebessystem unter jeder PHP-Version zu testen. Denn nur weil es bei dir keine Notices und Warnings gibt, heisst es nicht, dass es überall so ist.

Ok, das kann ich gelten lassen. Beispiele hättest du nicht zufällig gerade parat? Andererseits, ich benötige PHP nur für meine private Website, also wäre mir das auch erstmal egal.

Aus dem Grund bricht ein Script bei sowas ja auch nicht ab.

Definiere mal Script ein bisschen näher... ein Pythonskript bricht (bei meinen beiden Beispielen) sehr wohl ab. Zu Recht. Bei Perl weiß ich es ehrlich gesagt nicht mehr.

[dedlfix]

Tach!

Also wenn bei deinem Auto die Warnleuchte kommt, dass das Scheibenwaschwasser zu wenig ist, soll sofort der Motor ausgehen und nicht mehr anspringen?
Dieser Vergleich hinkt schon nicht mal mehr. Wenn bei meinem Auto der Motor fehlt, es aber trotzdem fährt, hätte ich schon gerne, dass es stoppt, ja.

Wenn der Motor fehlt, gibt es nicht nur eine Notice, dann kommt ein Fatal Error.

Ansonsten hast du ja den Tip bekommen, einen eigenen error-handler zu definieren. Und viel Spass dabei, dein Script unter jedem Betriebessystem unter jeder PHP-Version zu testen. Denn nur weil es bei dir keine Notices und Warnings gibt, heisst es nicht, dass es überall so ist.

Solch großartige Änderungen gibt es da nicht. An Notice werfenden Dingen sind mir seit Jahren keine neuen über den Weg gelaufen. Die letzten Änderungen, an die ich mich erinnere, betrafen Strict-Meldungen beim Einführen von PHP 5. (Und Strict kann man in der Regel völlig problemlos ignorieren.)

dedlfix.

[M.]

Mahlzeit,

Solch großartige Änderungen gibt es da nicht. An Notice werfenden Dingen sind mir seit Jahren keine neuen über den Weg gelaufen. Die letzten Änderungen, an die ich mich erinnere, betrafen Strict-Meldungen beim Einführen von PHP 5. (Und Strict kann man in der Regel völlig problemlos ignorieren.)

Die Unterschiede liegen in den Laufzeitumgebungen. Apache-Modul, CLI und CGI verhalten sich unterschiedlich, ebenso wie Linux und Windows-Versionen.

Grad vom Apache zum IIS gibts Unterschiede in den Umgebungsvariablen die evtl. Notices verursachen aber ansonsten keine Probleme machen. Der Programmieraufwand wäre dann evtl. höher als der Nutzen, auch wenn ich dafür bin, jede Notice zu eliminieren, kann man es übertreiben ;)

[dedlfix]

Tach!

Solch großartige Änderungen gibt es da nicht. An Notice werfenden Dingen sind mir seit Jahren keine neuen über den Weg gelaufen.
Die Unterschiede liegen in den Laufzeitumgebungen. Apache-Modul, CLI und CGI verhalten sich unterschiedlich, ebenso wie Linux und Windows-Versionen. Grad vom Apache zum IIS gibts Unterschiede in den Umgebungsvariablen die evtl. Notices verursachen aber ansonsten keine Probleme machen.

Du meinst also nicht das grundlegende Konzept, wann es Notices gibt, sondern nur die näheren Umstände, wenn man sich auf das Vorhandensein von bestimmten äußeren Dingen verlässt. Das wäre aber fahrlässig - nicht im Sinne PHPs, sondern im Sinne der Anwendung. Es hat ja seinen Sinn, dass man bestimmte Werte abfragt. Wenn diese nicht existieren, sollte nicht PHP schreien sondern die Anwendung. Das wäre auch bei Formulareingaben der Fall. Und ich denke, dieses Prinzip der Prüfung von bereitgestellten Werten kennt er bereits aus den andere Sprachen.

Der Programmieraufwand wäre dann evtl. höher als der Nutzen, auch wenn ich dafür bin, jede Notice zu eliminieren, kann man es übertreiben ;)

dedlfix.

[M.]

Mahlzeit,

C, Java, Python, Erlang, Eiffel, Fortran um mal die zu nennen, mit denen ich produktiv gearbeitet habe.

Das hatte ich vermutet. Und bei C kann ich dir definitiv sagen, du hast unrecht. Wenn du bei Warnings abbrechen willst, musst du das explizit angeben.
Und wenn du das in einer Produktivumgebung machst, sollte dich dein Auftraggeber rauswerfen.
Damit verhinderst du, dass ein Programm unter einer anderen als deiner eigenen Umgebung kompiliert.

Wenn du nicht in der Lage bist, ein lauffähiges Programm zu schreiben, das auch bei Warnings kompiliert und fehlerfrei läuft, hast du noch nie produktiv programmiert. Denn genau das macht produktivität aus, auf möglichst vielen Umgebungen ohne Änderung lauffähig.

Dieser Vergleich hinkt schon nicht mal mehr. Wenn bei meinem Auto der Motor fehlt, es aber trotzdem fährt, hätte ich schon gerne, dass es stoppt, ja.

Wenn du eine undefinierte Variable mit einem fehlenden Motor vergleichst, hast du nichts verstanden. Ein fehlender Motor ist ein Fatal-Error und führt dazu, dass dein AUto nicht mehr fährt. Wenn eine Glühbirne ausfällt ist das ein Warning, das sollte bei Gelegenheit repariert werden. Und wenn das Scheibenwasser ausgeht ist das eine Notice, weil das Auto ohne Scheibenwaschwasser immer noch ohne Probleme und ohne Gefahr zu benutzen ist. Darum kannst du dich kümmern, wenn sicherheitsrelevante Dinge erledigt sind.

Definiere mal Script ein bisschen näher... ein Pythonskript bricht (bei meinen beiden Beispielen) sehr wohl ab. Zu Recht. Bei Perl weiß ich es ehrlich gesagt nicht mehr.

Du redest die ganze Zeit von PHP und bringst jetzt Beispiele in Python und Perl? Wenn du dich nicht entscheiden kannst, bin ich raus, denn eine gewissen Beratungsresitenz zeigt alleine dieser Absatz.