Sammelaktion: Fehlermeldungen von PHP

[Tom]

Hello,

um alle möglichen Fehlermeldungen in PHP klassifizieren zu können, muss ich die erst einmal sammeln. Dafür benötige ich Eure Hilfe.

Jedes Mal, wenn eine Fehlermeldung in PHP aufgetreten ist, sendet sie mir bitte komplett zu.
Vergesst aber bitte nicht, den Kontext dazu zu liefern, also in welchem Zusammanhang die Fehlermeldung aufgetreten ist.

PHP hat es bis heute, trotz mehrerer "Eingaben" bei den "Königen von PHP", nicht geschafft, den Fehlern eindeutige Fehlernummern zuzuordnen. Stattdessen kommen textuelle Fehlermeldungen, von denen ich bis heute noch nicht einmal eine vollständige Liste vorliegen habe und sogar befürchte, dass sie an unterschiedlichen Stellen zum selben Fehler auch noch unterschiedliche Texte liefern.

Bitte sendet die Meldungen nebst kurzer Erklärung, wie es eurer Meinung nach dazu kam einfach an mein eMail-Postfach

[e-mail]?subject=forum_php-error

Geplant ist eine Zusammenstellung
mit Klassifizierung des Fehlers
und Hinweisen darauf, wo man suchen sollte

Das Ganze wird dann ein Wiki-Artikel

Da die Fehlermeldungen immer personalisierte Inhalte enthalten, habe ich _kein_ _Uploadformular_ dafür bereitgestellt. Eine eMail mit kurzen Erläuterungen ist mir lieber.

Ich würde mich auch freuen, wenn eine Zeit lang ein Hinweis auf die Sammelaktion im Kopf des Forums erscheinen könnte.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hi,

um alle möglichen Fehlermeldungen in PHP klassifizieren zu können, muss ich die erst einmal sammeln. Dafür benötige ich Eure Hilfe.

den Ansatz unterstütze ich "im Geiste", und gern auch aktiv durch Zusenden von Fehler-Informationen.

PHP hat es bis heute, trotz mehrerer "Eingaben" bei den "Königen von PHP", nicht geschafft, den Fehlern eindeutige Fehlernummern zuzuordnen. Stattdessen kommen textuelle Fehlermeldungen, von denen ich bis heute noch nicht einmal eine vollständige Liste vorliegen habe und sogar befürchte, dass sie an unterschiedlichen Stellen zum selben Fehler auch noch unterschiedliche Texte liefern.

Das mag sein. Aber wäre es nicht einfacher, eine solche Liste anhand des Quellcodes von PHP zu generieren? Ich sage nicht, dass das ein Spaziergang wäre - ich habe mir vor einigen Jahren schon mal den Quellcode von PHP heruntergeladen, um nachzusehen, wie ein bestimmtes Detail implementiert ist. Daher habe ich eine ungefähre Vorstellung davon, wieviel "Material" das ist und wie schwer es ist, da durchzusteigen.
Trotzdem denke ich, dass dieser Ansatz zielstrebiger wäre, als das mehr oder weniger zufällige Auftreten von Fehlern abzuwarten und nur nach den Symptomen zu gehen.

Bitte sendet die Meldungen nebst kurzer Erklärung, wie es eurer Meinung nach dazu kam einfach an mein eMail-Postfach
Das Ganze wird dann ein Wiki-Artikel

Okay, notiert. Ich bin gespannt.

Schönes Wochenende noch,
 Martin

[Tom]

Hello,

Aber wäre es nicht einfacher, eine solche Liste anhand des Quellcodes von PHP zu generieren?

DU musst wieder den ganzen Spaß verderben.

Latürnich(sic!) wäre das machbar. Aber das würde monatelangen Einzelkampf in meiner Dachstube bedeuten und hier im Forum hätten wir nichts zu lachen.

Und erläutert sind die Meldungen davon auch noch nicht.

"SelfHTML-Forum sammelt für PHP" klingt doch da bei Heise und den übrigen Medien viel besser, als "Tom sitzt in seiner Dachstube und sucht Fehlermeldungen"

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[MudGuard]

Hi,

Aber wäre es nicht einfacher, eine solche Liste anhand des Quellcodes von PHP zu generieren?
Latürnich(sic!) wäre das machbar. Aber das würde monatelangen Einzelkampf in meiner Dachstube bedeuten und hier im Forum hätten wir nichts zu lachen.

Nur mal so als Idee:

Die Fehlermeldung besteht ja nicht nur aus der Meldung an sich, sondern auch noch aus betroffenem Script und Zeilennummer (und ggf. noch mehr).

Ich könnte mir vorstellen, daß das Zusammentragen dieser Information in einer Funktion geschieht.
Wenn man diese Funktion im Quelltext findet, kann man dann auch nach den Aufrufen der Funktion suchen und damit die Fehlermeldungstexte finden.

Ersatzweise: die Daten zur Meldung werden in einer Datenstruktur zusammengetragen. Dann danach suchen, wo diese befüllt wird ...

cu,
Andreas

[Tom]

Hello,

Nur mal so als Idee:

Die Fehlermeldung besteht ja nicht nur aus der Meldung an sich, sondern auch noch aus betroffenem Script und Zeilennummer (und ggf. noch mehr).

Ich könnte mir vorstellen, daß das Zusammentragen dieser Information in einer Funktion geschieht.
Wenn man diese Funktion im Quelltext findet, kann man dann auch nach den Aufrufen der Funktion suchen und damit die Fehlermeldungstexte finden.

Ersatzweise: die Daten zur Meldung werden in einer Datenstruktur zusammengetragen. Dann danach suchen, wo diese befüllt wird ...

Das stimmt. Ich könnte sämtliche Quellcode-Dateien automatisiert durchsuchen lassen, sofern ich eine RegExp dafür zusammengebastelt bekomme. Das müsste ich dann bei jedem Release aufs Neue durchführen :-O

Die werden aber auch aus dem Kontext zusammengetragen, also jeweils an zwei bis drei Stellen aufsummiert.

Das wäre dann die "einsame Dachkammernummer". Wenig amusant, aber vermutlich bleibt mir nichts anderes übrig.

Ich habe gestern noch mit der Funktion errror_get_last() herumhantiert. Die hat zwar nicht das Scope-Problem von $php_errormsg, aber dafür kann man ihr keine Fehlermeldung zuweisen, nur einen sogenannten Usererror auslösen. Der schlägt aber dann sofort durch und bricht die Ausführung ab.

Die Funktion ist also nur für "offizielle" Laufzeitfehler brauchbar, für meine allgemeinen Zwecke also unbrauchbar. Ich will ja auch eigene Fehler, die sich z.B. aus Nichteinhaltung von Typenvorgaben, Ranges, Zwischenergebnissen, usw. in der Fehlervariablen auffangen können. Anders kann man ja Laufzeitverhalten nicht kontrollieren. Und ich möchte nicht zwei unterschiedliche Fehlerbehandlungssysteme parallel haben.

Und wenn man sich dann überlegt, dass dieser ganze Aufwand für Programme ist, die im Durchschnitt vielleicht 10ms laufen,

dafür aber millionenfach :-O

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Nur mal so als Idee:

Die Fehlermeldung besteht ja nicht nur aus der Meldung an sich, sondern auch noch aus betroffenem Script und Zeilennummer (und ggf. noch mehr).

Ich könnte mir vorstellen, daß das Zusammentragen dieser Information in einer Funktion geschieht.

Aus langjähriger Erfahrung mit alter, chaotisch gewachsener Software und aus Andeutungen in diversen Artikeln über PHP: Nein, ich glaube nicht, dass es EINE zentrale Funktion in PHP gibt, durch die alle Fehlermeldungen laufen. Wahrscheinlich gibt es so etwa drei bis fünf häufig benutzte Wege und noch so etwa 10 bis 20 Schleichwege. Das wäre jedenfalls meine Grundannahme.

Bevor ich mir die Mühe machen würde, im PHP-Source herumzuwühlen, würde ich erst einmal die vorhandene Dokumentation sichten. Eine Übersicht aller Fehlermeldungen sollte Teil der Dokumentation sein. Zumindest ist die das in Perl: perldiag.

Das Durchwühlen des Source würde ich automatisieren: Im Source sollte es außer Warn- und Fehlermeldungen eigentlich nur noch PHP-Keywords und ein paar Namen von dynamisch nachgeladenen Libraries und Funktionen geben. Vielleicht noch ein paar "magic numbers" in String-Form. Schritt 1 wäre also, ALLE String-Konstanten aus dem Source zu fischen. Dann darüber uniq laufen lassen. Dann diejenigen rauswerfen, die als Keywords in der Doku gelistet sind (List of Function Aliases, List of Reserved Words, List of Resource Types, List of Parser Tokens). Danach ist Handarbeit angesagt.

Ich vermute, dass PHP auch Fehlerstrings aus gelinkten Libraries ausgibt. Die der libc kann man (wenigstens auf Linux-, BSD- und MacOSX-Systemen) nach #include <errno.h> aus const char *sys_errlist[] lesen, die Länge dieses Arrays ist in int sys_nerr zu finden. Was andere Libraries angeht: RTFM.

Den Ansatz, PHP-Meldungen aus dem Forum oder dem Rest des Internet zu sammeln, halte ich für wenig sinnvoll. Es wird genügend Leute geben, die Schrott posten, schon allein, weil sie lieber die Meldung falsch abtippen statt sie zu kopieren. Es wird jede Menge Redundanzen geben, und etwas exotischere Meldungen werden gar nicht auftauchen. Außerdem werden Spaßvögel falsche Meldungen liefern.

Alexander

[Tom]

Hello,

Den Ansatz, PHP-Meldungen aus dem Forum oder dem Rest des Internet zu sammeln, halte ich für wenig sinnvoll. Es wird genügend Leute geben, die Schrott posten, schon allein, weil sie lieber die Meldung falsch abtippen statt sie zu kopieren. Es wird jede Menge Redundanzen geben, und etwas exotischere Meldungen werden gar nicht auftauchen. Außerdem werden Spaßvögel falsche Meldungen liefern.

Stimmt auch wieder.
Aber Spaß gehört doch zur Arbeit ;-)

Ich habe mir die Sources bezüglich der Thematik selbstverständlich schon angesehen. Ich rühre wegen dieser Angelegenheit schon seit ca. 2008. Aber da bis heute bei den "PHP-Königen" keine Einsicht erfolgt ist, möchte ich nun doch mal vorpreschen.

Es gibt einen "Quasi-Algorithmus", der zur Erzeugung der Fehlermeldungen eingehalten wird. Leider sind dessen einzelne Statements machmal breit gestreut im Source-Code. Man "addiert just in Time" die Teile des Fehlerstatements.

Die sind daher automatisiert schwer zu finden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Ich habe mir die Sources bezüglich der Thematik selbstverständlich schon angesehen. Ich rühre wegen dieser Angelegenheit schon seit ca. 2008. Aber da bis heute bei den "PHP-Königen" keine Einsicht erfolgt ist, möchte ich nun doch mal vorpreschen.

Kann es sein, dass einfach der Bedarf nicht da ist? Wenn da jetzt 5000 Leute anfragen, wird eher reagiert, als wenn du der einzige bist.
Und da selbst hier im Forum die Resonanz minimal ist, kann ich verstehen, dass bei sowas die Priorität eher gering ist.

Du müsstest ja sowas wie den suhosin-Patch etablieren, der dann auf vielen Distros automatisch installiert wird, was nicht einfach werden wird.

[Tom]

Hello,

Die Fehlermeldung besteht ja nicht nur aus der Meldung an sich, sondern auch noch aus betroffenem Script und Zeilennummer (und ggf. noch mehr).

Ich könnte mir vorstellen, daß das Zusammentragen dieser Information in einer Funktion geschieht.
Wenn man diese Funktion im Quelltext findet, kann man dann auch nach den Aufrufen der Funktion suchen und damit die Fehlermeldungstexte finden.

Ich habe mir das gerade nochmal im Source-Code von Version (5.4.28 NTS VC9) angesehen. Das wird absolut schwierig, die Fehlermeldungen auszufiltern. Sie setzen sich zusammen aus den Teilmeldungen der beteiligten Hierarchiestufen. Mein Beispiel ist immer "fopen()". Da kommt die Grundmeldung "failed to open stream", dann wird z.B. angehängt ": %s:// wrapper is disabled in the server configuration by allow_url_fopen=0", usw.

Da sind also auch noch Stringersetzungen (%s) an diversen Stellen vorher fällig.

Ich werde doch sammeln müssen. Die Grundmeldungen kann ich rausfischen; das geht aber nur manuell. Suchen nach dem Vorkommen von "errors" im Quelltext und dann die Umgebung nach dem Fehlertextstring absuchen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Ich habe mir das gerade nochmal im Source-Code von Version (5.4.28 NTS VC9) angesehen. Das wird absolut schwierig, die Fehlermeldungen auszufiltern. Sie setzen sich zusammen aus den Teilmeldungen der beteiligten Hierarchiestufen. Mein Beispiel ist immer "fopen()". Da kommt die Grundmeldung "failed to open stream", dann wird z.B. angehängt ": %s:// wrapper is disabled in the server configuration by allow_url_fopen=0", usw.

Da sind also auch noch Stringersetzungen (%s) an diversen Stellen vorher fällig.

Schau Dir bitte mal perldiag an. %s und andere Format-Strings bleiben dort bewußt stehen.

Übrigens: Perl selbst nutzt die Dokumentation (also perldiag.pod), um im Fehlerfall weitere Informationen zu liefern, sofern man das diagnostics-Modul lädt (use diagnostics;). Das geht auch offline, ohne Eingriff in das Programm, mit dem splain-Programm.

Beispiel:

  

>perl -Mstrict -e '$x=1'  

Global symbol "$x" requires explicit package name at -e line 1.  
Execution of -e aborted due to compilation errors.  
  

>perl -Mdiagnostics -Mstrict -e '$x=1'  

Global symbol "$x" requires explicit package name at -e line 1.  
Execution of -e aborted due to compilation errors (#1)  
    (F) You've said "use strict" or "use strict vars", which indicates  
    that all variables must either be lexically scoped (using "my" or "state"),  
    declared beforehand using "our", or explicitly qualified to say  
    which package the global variable is in (using "::").  
  
Uncaught exception from user code:  
        Global symbol "$x" requires explicit package name at -e line 1.  
Execution of -e aborted due to compilation errors.  
 at -e line 1  
  

>  

Alexander

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

Ich würde mich auch freuen, wenn eine Zeit lang ein Hinweis auf die Sammelaktion im Kopf des Forums erscheinen könnte.

Schreib einen Text und such dir eine Stelle aus ;-)

Matthias

[Claudius L.]

Hallo Tom,

Stattdessen kommen textuelle Fehlermeldungen, von denen ich bis heute noch nicht einmal eine vollständige Liste vorliegen habe und sogar befürchte, dass sie an unterschiedlichen Stellen zum selben Fehler auch noch unterschiedliche Texte liefern.

offenbar kann es keine vollständige Liste geben und offenbar trifft deine Befürchtung zu, dass derselbe Fehler zu unterschiedlichen Texten führen kann. Zumindest legt das die akzeptierte Antwort hier auf stackoverflow nahe. Bist du sicher, dass sich das Zusammentragen dann lohnt?

Viele Grüße
Claudius

[Tom]

Hello,

Stattdessen kommen textuelle Fehlermeldungen, von denen ich bis heute noch nicht einmal eine vollständige Liste vorliegen habe und sogar befürchte, dass sie an unterschiedlichen Stellen zum selben Fehler auch noch unterschiedliche Texte liefern.

offenbar kann es keine vollständige Liste geben und offenbar trifft deine Befürchtung zu, dass derselbe Fehler zu unterschiedlichen Texten führen kann. Zumindest legt das die akzeptierte Antwort hier auf stackoverflow nahe. Bist du sicher, dass sich das Zusammentragen dann lohnt?

Ja. Das Warum möchte ich bitte nicht öffentlich diskutieren. Ich habe mir etwas dabei gedacht :-O

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Ja. Das Warum möchte ich bitte nicht öffentlich diskutieren. Ich habe mir etwas dabei gedacht :-O

Es muss ja nicht diskutiert werden aber der Sinn dahinter würde mich schon interessieren (ich seh keinen weil ich bisher keine Probleme hatte, nach der Fehlermeldung den Fehler zu finden, xDebug hilft dabei). Denn wenn ich mir zusätzliche Arbeit mache will ich wissen, wofür ;)

Mal abgesehen davon, wenn ich komplette Fehlermeldungen, Warnings etc. weitergebe, stehen da Dinge drin, die niemanden was angehen, wie Pfade etc. Der Aufwand, sowas zu anonymisieren, ist enorm. Du solltest also ein Tool liefern, das die Arbeit erleichtert, denn dann bekommst du auch mehr Hilfe, wenn die Zusatzarbeit weniger ist.

[Tom]

Hello,

[...] der Sinn dahinter würde mich schon interessieren (ich seh keinen weil ich bisher keine Probleme hatte, nach der Fehlermeldung den Fehler zu finden, xDebug hilft dabei).

Das Fehlersystem für die Entwicklungszeit ist mMn auch ausreichend.
Mir geht es aber um die Fehlermeldungen (sollten wir sie da vielleicht besser Statusmeldungen nennen?) zur Laufzeit.

Die sind leider absolut dürftig und nicht besonders gut verwertbar.

Wenn z.B. ein fopen($filename, $mode) fehlschlägt, kann das unterschiedliche Ursachen haben. PHP gibt die im Fehlertext [message] auch bekannt, der Fehlertyp [type] ist aber immer 2. PHP kennt die Ursache aber -> siehe [message]. Leider sind die Meldungen in textueller Form zur Laufzeit schwer handhabbar, insbesondere, wenn man keine Liste aller Fehlertexte und ihrer möglichen Ursachen hat.

Die Liste versuche ich nun schon seit Jahren zu bekommen. Leider gibts da bei den PHP-Königen keine Reaktion, bzw. nur die pampige Auskunft "wieso, was willst Du denn? Die Fehlermeldungen werden doch ausgegeben". *Dankeschön*

Das nützt mir für die Programmsteuerung überhaupt nix, wenn die dann später im Betrieb "ausgegeben" werden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Das Fehlersystem für die Entwicklungszeit ist mMn auch ausreichend.
Mir geht es aber um die Fehlermeldungen (sollten wir sie da vielleicht besser Statusmeldungen nennen?) zur Laufzeit.

Ok, das macht mehr Sinn. Ich hab bei solchen Dingen immer den Fehler generell abgefangenund durch eigene Fehlernummer und -texte ersetzt. Dadurch stelle ich sicher, dass der Benutzer immer die gleiche Meldung bei gleichen Fehler bekommt.

Bin mal gespannt, wie sich dein Projekt entwickelt, wenn es sich ergibt, dass ich helfe, werde ich das tun ;)
BTW: Was hast du mit Erweiterungen wie z.B. Smarty vor? Die haben ein ähnliches System und werfen eigene Fehlermeldungen.

[Tom]

Hello,

BTW: Was hast du mit Erweiterungen wie z.B. Smarty vor? Die haben ein ähnliches System und werfen eigene Fehlermeldungen.

Oh M., jetzt hast Du mich aber demotiviert :-O

BTW:
Bist Du nun Temp-Bayer oder sitzt Du in MeckPomm? Bin einfach mal ein wenig neugierig.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Bist Du nun Temp-Bayer oder sitzt Du in MeckPomm? Bin einfach mal ein wenig neugierig.

Ich bin seit 41 Jahren sesshaft in Bayern (also seit man mich, gegen meinen Willen, in diese Welt gebracht hat ;))
In MeckPomm war ich nur einmal und bin mehrer male durchgefahren

[Tom]

Hello,

Ich bin seit 41 Jahren sesshaft in Bayern (also seit man mich, gegen meinen Willen, in diese Welt gebracht hat ;))

Na dann: passt scho!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello an die Profis,

Kleine Erweiterung meines Aufrufes

Bitte sendet die Fehlermeldungen nebst kurzer Erklärung, wie es eurer Meinung nach dazu kam einfach an mein eMail-Postfach

[e-mail]?subject=forum_php-error

Geplant ist eine Zusammenstellung
mit Klassifizierung des Fehlers
und Hinweisen darauf, wo man suchen sollte

Wie könnte man denn ggf. die Personalisierungen in den Fehlermeldungen finden und neutralisieren, solange man die texte noch nicht vorliegen hat?

Szenario:
---------
Jemand sendet seine Fehlermeldung.
Die wird jetzt eingetragen in eine Datenbank.

Die Tabelle sollte einen Unique Key auf "Fehlertext" haben, sodass keine Meldung doppelt eingetragen wird, sondern ggf, nur die zusätzlichen Metainformationen dazu aufgenommen werden:
* wann/ in welem Zusammenhang aufgetreten
* wo nach der Ursache gesucht
* wie beseitigt
* weitere Bemerkungen

Wenn die Meldungen aber personalisiert sind, hat jeder einen anderen Variablennanem, Dateinamen, Pfadnamen, ... in der Textmeldung stehen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

um das nicht zu unterschlagen:

es gibt auch noch

 error_get_last()  

Die Funktion steht im globalen Scope und liefert ein Array der Form:

  
Array  
(  
    [type] => 2  
    [message] => fopen(bekannt_ro.txt): failed to open stream: Permission denied  
    [file] => M:\USER\TOM\WebProgTests\Xampp\error_msg\error.php  
    [line] => 20  
)  
  

Leider sind die Fehlertypen [type] hier auch sehr grob.
Die eigentliche Ursache geht dann erst wieder aus [message] hervor: Permission denied

die Datei war "read only" und ich habe versucht, sie mit Filemode 'rb+' zu öffnen.

Das lässt sich leider durch die Bank so fortsetzen.
Die Fehlermeldungen sind leider nur auf die Entwicklungszeit ausgelegt, nicht auf die Laufzeit.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Fortsetzung

error_get_last()

>   
> Die Funktion steht im globalen Scope und liefert ein Array der Form:  
>   
> ~~~php
  

> Array  
> (  
>     [type] => 2  
>     [message] => fopen(bekannt_ro.txt): failed to open stream: Permission denied  
>     [file] => M:\USER\TOM\WebProgTests\Xampp\error_msg\error.php  
>     [line] => 20  
> )  
>   
> 

An der Art der Meldung (textuell) kann man zwar nichts ändern, aber nun habe ich wenigstens raudgefunden, wie ich auf ini_set() und $php_errormsg verzichten kann und meine eigene globale Variable.

Man kann innerhalb einer Funktion doch einen Errortext zuweisen, ohne dass das Programm abbricht

  
    @trigger_error('2099 - Benutzermeldung', E_USER_NOTICE);  
  

Ich hatte da wohl versehentlich E_USER_ERROR benutzt; das führt dann zum Programmabbruch.

Dann steht die nach dem "return false" auch außerhalb der Funktion zur Verfügung und kann mit error_get_last() abgeholt werden. Übesetzt werden in eine eindeutige Fehlernummer muss sie leider trotzdem noch. Aber wenigstens schon mal ein Problem weniger.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[tami]

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

tami

[tami]

http://www.smashingmagazine.com/2011/11/30/a-guide-to-php-error-messages-for-designers/
mfg

tami

[Tom]

Hello,

http://www.smashingmagazine.com/2011/11/30/a-guide-to-php-error-messages-for-designers/

Log_errors ist interessant.
Und Google werde ich auch mal bitten, mir mehr als 100 Stück zu liefern.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[tami]

hi,

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

Ok. Dss wsr schon verlinkt ...
mfg

tami

[hotti]

hi,

um alle möglichen Fehlermeldungen in PHP klassifizieren zu können, muss ich die erst einmal sammeln. Dafür benötige ich Eure Hilfe.

Wozu?

PHP hat es bis heute, trotz mehrerer "Eingaben" bei den "Königen von PHP", nicht geschafft,

Aha ;)

den Fehlern eindeutige Fehlernummern zuzuordnen. Stattdessen kommen textuelle Fehlermeldungen...

Sollte doch reichen...

  
if($eo = error_get_last()){  
   throw new Exception(  print_r($eo, 1)   );  
}  

... so kriegst Du ALLE Fehler. Zuerst den Letzten, wo Du bereinigst. Falls immer noch Fehler sind, ist der bis dahin Vorletzte der Letzte und error_get_last() schlägt erneut zu. Die EX gleich im Browser ausgeben. Am Besten gleich so entwickeln. Wenn Du damit durch bist, guckst Du LogFile. Da sollte sich dann nichts mehr ansammeln.

[Tom]

Hello Rolf,

drück mal auf STOP, spul zurück, lies den ganezn Thread durch, mach dann einen Plan und drück dann erst wieder auf RECORD.

Inverstanden?

Sonst müsste ich jetzt den großen Hochfrequenzmagneten bestellen für Dein Posting!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

Stelle Dir doch mal die Frage nach dem Nutzen einer solchen Sammlung. Die Porter wird das kaum beeindrucken. Noch Weniger einen Entwickler, der unter Zeitdruck steht, der will nicht bis ins Kleinste wissen, was da knallt, sondern der will nur wissen wo es knallt und wie er das verhindert. Selbst wenn er sich abends bis spät in die Nacht hinsetzt und Fehlerkataloge wälzt (falls vorhanden) wird ihm das keiner danken, am Wenigsten sein Chef. Das ist nunmal die Praxis. Wohl kenne ich einen CPAN-Entwickler, der mögliche Anwendungsfehler seiner Module filigran katalogisiert, tatsächlich aber keinen Perl-Entwickler, dem das hilfreich wäre.

Nicht umsonst gibt es in Perl das Carp Modul und wer seine Module selbst entwickelt, wird das sogar so machen, dass bereits im Modul zwischen Anwendungsfehlern (API) und Eingabefehlern (User) unterschieden wird. Beispielsweise kann in einem Modul ganz genau festgestellt werden, was am eingegebenen Datum '29.2.2003' falsch ist und der Entwickler, den in diesem Fall keine Schuld trifft, reicht einfach nur die Exception ungesehen durch bis zum Browser, wo der Benutzer seinen Fehler korrigieren kann. Und ja: Der Entwickler muss sich darauf verlassen können, dass da nicht irgendeine Nummer durchgereicht wird, sondern eine für den Benutzer aussagekräftige und verständliche Fehlermeldung ;)

[1UnitedPower]

Meine Herren!

Deinen Ehrgeiz in allen Ehren, aber mit deinem bisherigen Konzept sehe ich nicht viele Chancen dafür, dass dein Projekt erfolgreich werden könnte.

Das Projekt ist zunächst mal sehr ambitioniert, ich glaube du unterschätzt den Arbeitsaufwand. Und du machst dir noch mehr Arbeit, wo sie leicht vermeidbar wäre. Wenn alle Fehlerberichte per Mail direkt an dich gehen, dann werden massenweise Dubletten und falsche Positive bei dir eintrudeln, diese überschaubar zu verwalten ist ansich schon eine Herausforderung. Dieser Arbeitsaufwand kann aber einfach minimiert werden, wenn man die Fehlerberichte einer transparenten Verwaltung unterzieht *schiele auf das Wiki*. Ein Issue-Tracker wie bei GitHub könnte auch nützlich sein, um die Fehlermeldungen mit der Öffentlichkeit direkt vor Ort zu diskutieren. Außerdem schätze ich die Leistungsbereitschaft der Menschen deutlich höher ein, wenn die Arbeit von kollaborativer Software unterstützt wird und wenn der Fortschritt für jeden Teilnehmer zu jeder Zeit beobachtbar ist.