Aloha ;) > > Dem entsprechend wird es dann wohl auch keine offizielle Liste dafür geben. Bleibt die Frage, wofür du eine brauchst — vielleicht lässt sich das ja auch anders lösen. > > Was werde ich damit schon anfangen: erwartbare und unerwartete Laufzeitfehler voneinander trennen und darauf reagieren in den Applikationen. Was erwartbar ist und was unerwartbar ist ändert sich ja mit der Anwendung. Typischerweise ist die Liste erwartbarer Fehler recht kurz (ansonsten wäre das eher ein Zeichen für schlechtes Programmdesign), so dass es keine Mühe machen sollte, sich die Codes der erwartbaren Fehler, die ja im Lauf des Debugging sowieso immer mal wieder aufkommen sollten, zu notieren, und dann entsprechend danach zu filtern. Einen großen Vorteil einer umfassenden Liste kann ich da jetzt nicht erkennen; auch aus einer Liste müsstest du dir "deine" Fehlernummern noch rausziehen. > Anders habe ich es schon relativ gut gelöst, indem ich [error_get_last()](http://php.net/manual/en/function.error-get-last.php) und [error_clear_last()](http://php.net/manual/en/function.error-clear-last.php) benutzte. Die textuellen Meldungen sind immer gleich aufgebaut, auch wenn sie bei Kombinationsfehlern geringfügig abweichen. Ich habe mir diese Meldungen "zurückgeparst" und kategorisiert in eindeutige Fehlerursachen-Nummern. Dann bist du ja schon recht gut aufgestellt. > Das ist aber eine inoffizielle Liste, die sich mit dem Versionswechsel auf PHP 7.x erheblich ändern könnte. Ich habe leider noch keins in die Finger bekommen. In dem Fall kannst du ja gleich vorgehen wie bisher, nur statt wie bisher die textuelle Repräsentation zu nehmen könntest du auf getCode() zurückgreifen - das würde ich für sinnvoll halten. Bestehende Fehlercodes werden sich eher nicht ändern, denke ich. > Und wenn dann getCode() aus der Exception-Class schon eindeutige Antworten geben würde, müsste ich das Rad ja nicht nochmal wieder neu erfinden. Richtig. "Eindeutige Antworten" vielleicht nicht, aber zumindest ausreichend unterscheidbare. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

Aloha ;) > > Dem entsprechend wird es dann wohl auch keine offizielle Liste dafür geben. Bleibt die Frage, wofür du eine brauchst — vielleicht lässt sich das ja auch anders lösen. > > Was werde ich damit schon anfangen: erwartbare und unerwartete Laufzeitfehler voneinander trennen und darauf reagieren in den Applikationen. Was erwartbar ist und was unerwartbar ist ändert sich ja mit der Anwendung. Typischerweise ist die Liste erwartbarer Fehler recht kurz (ansonsten wäre das eher ein Zeichen für schlechtes Programmdesign), so dass es keine Mühe machen sollte, sich die Codes der erwartbaren Fehler, die ja im Lauf des Debugging sowieso immer mal wieder aufkommen sollten, zu notieren, und dann entsprechend danach zu filtern. Einen großen Vorteil einer umfassenden Liste kann ich da jetzt nicht erkennen; auch aus einer Liste müsstest du dir "deine" Fehlernummern noch rausziehen. > Anders habe ich es schon relativ gut gelöst, indem ich [error_get_last()](http://php.net/manual/en/function.error-get-last.php) und [error_clear_last()](http://php.net/manual/en/function.error-clear-last.php) benutzte. Die textuellen Meldungen sind immer gleich aufgebaut, auch wenn sie bei Kombinationsfehlern geringfügig abweichen. Ich habe mir diese Meldungen "zurückgeparst" und kategorisiert in eindeutige Fehlerursachen-Nummern. Dann bist du ja schon recht gut aufgestellt. > Das ist aber eine inoffizielle Liste, die sich mit dem Versionswechsel auf PHP 7.x erheblich ändern könnte. Ich habe leider noch keins in die Finger bekommen. In dem Fall kannst du ja gleich vorgehen wie bisher, nur statt wie bisher die textuelle Repräsentation zu nehmen könntest du auf getCode() zurückgreifen - das würde ich für sinnvoll halten. Bestehende Fehlercodes werden sich eher nicht ändern, denke ich. > Und wenn dann getCode() aus der Exception-Class schon eindeutige Antworten geben würde, müsste ich das Rad ja nicht nochmal wieder neu erfinden. Richtig. "Eindeutige Antworten" vielleicht nicht, aber zumindest hinreichend eindeutige. Grüße, RIDER -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller # [Twitter](https://twitter.com/Camping_RIDER) # [Steam](http://steamcommunity.com/id/Camping_RIDER) # [YouTube](https://www.youtube.com/user/RidersFlame) # [Self-Wiki](http://wiki.selfhtml.org/wiki/Benutzer:Camping_RIDER) # [Selfcode](http://community.de.selfhtml.org/fanprojekte/selfcode.htm): sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[