Fehlermeldung vermeiden

[TS]

Hello,

wie kann ich denn die Fehlermeldung abfangen, ohne dass sie angezeigt wird?

Warning: mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket

Ein '@' vor dem mysqli_connect() hilft leider nicht. Die Meldung kommt trotzdem.

Liebe Grüße
Tom S.

[pl]

try/catch vielleicht? Aber ich hab das jetzt nicht getestet.

MfG

[TS]

Hello,

try/catch vielleicht? Aber ich hab das jetzt nicht getestet.

Die Applikation ist prozedural erstellt, da habe ich das noch nie eingesetzt...
Aber wo Du es jetzt sagst. Try Catch funktioniert wohl auch ohne OOP tztz

Liebe Grüße
Tom S.

[pl]

So ähnlich ging es einem gewissen Reinhold M. als er das Erstemal mit seinem Vater die große Fermeda/Villnöß bestiegen hatte und oben feststellen musste: Aha, hinterm Horizont gehts ja weiter 😉

[dedlfix]

Tach!

try/catch vielleicht? Aber ich hab das jetzt nicht getestet.

Die Applikation ist prozedural erstellt, da habe ich das noch nie eingesetzt...
Aber wo Du es jetzt sagst. Try Catch funktioniert wohl auch ohne OOP tztz

Hast du vielleicht mysqli_report() mit MYSQLI_REPORT_STRICT oder MYSQLI_REPORT_ALL aufgerufen?

Dass Exceptions geworfen werden und @ nicht wirkt, konnte ich jedenfalls ohne diese Einstellungen nicht nachvollziehen. Andererseits gab es mit obigem Funktionsaufruf und ohne abgefangene Exception einen Fatal Error. Vielleicht ist das im Detail auch ein versionsabhängiges Verhalten.

dedlfix.

[TS]

Hello,

try/catch vielleicht? Aber ich hab das jetzt nicht getestet.

Die Applikation ist prozedural erstellt, da habe ich das noch nie eingesetzt...
Aber wo Du es jetzt sagst. Try Catch funktioniert wohl auch ohne OOP tztz

Hast du vielleicht mysqli_report() mit MYSQLI_REPORT_STRICT oder MYSQLI_REPORT_ALL aufgerufen?

Dass Exceptions geworfen werden und @ nicht wirkt, konnte ich jedenfalls ohne diese Einstellungen nicht nachvollziehen. Andererseits gab es mit obigem Funktionsaufruf und ohne abgefangene Exception einen Fatal Error. Vielleicht ist das im Detail auch ein versionsabhängiges Verhalten.

Nicht wissentlich. Ich probier nachher erstmal, die Exception abzufangen. Bin jetzt unterwegs...

BTW: Wo finde ich eine Liste mit den Exception-Codes? Im Manual habe ich keine gesehen.

Liebe Grüße
Tom S.

[dedlfix]

Tach!

BTW: Wo finde ich eine Liste mit den Exception-Codes? Im Manual habe ich keine gesehen.

Meines Wissens werden nach wie vor keine Exceptions systemweit geworfen, sondern nur bestimmte Extensions tun dies, und das auch nur auf Anforderung. Die mysqli-Extension wird hauptsächlich die Meldungen durchreichen, die vom MySQL-Server oder der Client-API erzeugt werden. Eine Liste wirst du also in der MySQL-Dokumentation finden.

dedlfix.

[TS]

Hello,

BTW: Wo finde ich eine Liste mit den Exception-Codes? Im Manual habe ich keine gesehen.

Meines Wissens werden nach wie vor keine Exceptions systemweit geworfen, sondern nur bestimmte Extensions tun dies, und das auch nur auf Anforderung. Die mysqli-Extension wird hauptsächlich die Meldungen durchreichen, die vom MySQL-Server oder der Client-API erzeugt werden. Eine Liste wirst du also in der MySQL-Dokumentation finden.

Es gibt da ein Beispiel mit "Division durch Null" oder so ähnlich.
Und dann gibt es die Methode getCode()

Da lag es nahe, dass es einheitliche Codes zu den Fehlern gibt.

Das Phänomen mit dem '@' hat sich geklärt. Das Modul hat ein Singleton für die Datenbankverbindung eines Arbeitsbereiches. Die Funktion dafür ist aber bedingt eingebunden (if (!function_exists(...)) und ist in der zentralen functions.lib.php schon vorhanden. Dort gab es kein '@' vor dem mysqli_connect().

Das kommt davon, wenn man alte Sachen von Anderen anfasst :-O

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

Es gibt da ein Beispiel mit "Division durch Null" oder so ähnlich.
Und dann gibt es die Methode getCode()

Da lag es nahe, dass es einheitliche Codes zu den Fehlern gibt.

Ich fürchte nicht. Aus der von dir verlinkten Seite:

Returns the exception code as integer in Exception but possibly as other type in Exception descendants (for example as string in PDOException).

und

when raising an Exception with no error code explicitly defined, getCode() returns the integer 0

Das legt doch schon deutlich nahe, dass erstens jede Extension ihre eigenen Fehlercodes definiert und zweitens Fehlercodes nicht einmal einem einheitlichen Format folgen.

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.

Grüße,

RIDER

[TS]

Hello,

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.

Anders habe ich es schon relativ gut gelöst, indem ich error_get_last() und error_clear_last() 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.

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.

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.

Liebe Grüße
Tom S.

[Camping_RIDER]

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() und error_clear_last() 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

[TS]

Hello,

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.

Development by coincidence?

Der Begriff "Fehlermeldung" in der Programmierung wird leider immer noch falsch verstanden. Darum spricht man im Webserverumfeld auch "schon" von Statusmeldungen. Man hat also geringfügig dazugelernt in ca. 30-100 Jahren Programmiertechnik.

Viele TOCCTOU-Probleme würde es nicht geben, wenn die Programmierer stattdessen aktiv mit Fehlermeldungen arbeiten würden ;-)

Nur dazu muss der Programmierer die zur Verfügung stehenden auch kennen, und nicht darauf angewiesen sein, sie durch Zufall zu entdecken.

BTW:  
könnte ein Tag-Verantwortlicher bitte mal die Threads des Tags "Programmiertechnk" mit "Programmiertechnik" updaten und den falschen Tag dann entfernen?  

Liebe Grüße
Tom S.

[Matthias Apsel]

Hallo TS,

BTW:  
könnte ein Tag-Verantwortlicher bitte mal die Threads des Tags "Programmiertechnk" mit "Programmiertechnik" updaten und den falschen Tag dann entfernen?  

Das hab ich doch gestern schon gemacht⁉️

Bis demnächst
Matthias

[TS]

Hello Matthias,

BTW:
könnte ein Tag-Verantwortlicher bitte mal die Threads des Tags "Programmiertechnk" mit "Programmiertechnik" updaten und den falschen Tag dann entfernen?

Das hab ich doch gestern schon gemacht⁉️

Der falsche Tag steht aber noch immer in der Vorschlagsliste. Hast Du die auch korrigiert?

Liebe Grüße
Tom S.

[TS]

Hello,

BTW:
könnte ein Tag-Verantwortlicher bitte mal die Threads des Tags "Programmiertechnk" mit "Programmiertechnik" updaten und den falschen Tag dann entfernen?

Das hab ich doch gestern schon gemacht⁉️

Der falsche Tag steht aber noch immer in der Vorschlagsliste. Hast Du die auch korrigiert?

Sorry, was ist denn nun schon wieder passiert? Jetzt habe ich - ohne es zu wollen und zu merken - wohl nocz eine Leiche angelegt. "pro" sollte nicht entstehen, auch wenn es ja ganz hübsch klingt ;-)

Liebe Grüße
Tom S.

[Matthias Apsel]

Hallo TS,

Der falsche Tag steht aber noch immer in der Vorschlagsliste.

Das Tag 😉

Hast Du die auch korrigiert?

Jetzt ja.

Bis demnächst
Matthias

[TS]

Hello,

Der falsche Tag steht aber noch immer in der Vorschlagsliste.

Das Tag 😉

Hast Du die auch korrigiert?

Jetzt ja.

Danke.

Und wenn Du Janosch nun noch erläutern könntest, was die proaktive Nutzung von Fehlermeldungen mit der Vermeidung von Race-Conditions zu tun haben könnte usw., dann hättest Du mir mein (sic!) Tag gerettet ;-)

Sonst müsste ich die schlauen Formulierungen zum Thema aus den Annalen des Archivs heraussuchen, damit ich sie nicht selber noch einmal erfinden muss :-O

Liebe Grüße
Tom S.

[Camping_RIDER]

Aloha ;)

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.

Development by coincidence?

Nö. Was erwartbar ist weißt du schon vorher und die Codes bekommst du beim Debugging sowieso mit. Falls nicht kannst du sie dir ausgeben lassen. Da hat nichts mit Zufall zu tun.

Der Begriff "Fehlermeldung" in der Programmierung wird leider immer noch falsch verstanden. Darum spricht man im Webserverumfeld auch "schon" von Statusmeldungen. Man hat also geringfügig dazugelernt in ca. 30-100 Jahren Programmiertechnik.

Hm? Der Begriff „Fehlermeldung“ beschreibt definitiv etwas anderes als der Begriff „Statusmeldung“ und die Begriffe sind in den meisten Fällen sicher auch nicht austauschbar. Das hängt stark vom Design des zugrundeliegenden Systems ab, ob jetzt Fehlermeldungen oder Statusmeldungen generiert werden. HTTP beispielsweise generiert ganz klar Statusmeldungen, während HTTP-Fehlermeldungen nur ein Subset dieser Statusmeldungen sind. Programmiersprachen wie Java geben Fehlermeldungen (error) und dokumentieren Ausnahmesituationen (exception), wobei nicht behandelte Ausnahmen zu einem Fehler werden, aber sie liefern keine Statusmeldungen.

Viele TOCCTOU-Probleme würde es nicht geben, wenn die Programmierer stattdessen aktiv mit Fehlermeldungen arbeiten würden ;-)

TOCCTOU? Du meinst sicher TOCTTOU. Den Zusammenhang zwischen Fehlermeldungen und diesem Problem, das eine race-condition und damit eine Unzulänglichkeit im Programmdesign beschreibt ist mir nicht klar.

Nur dazu muss der Programmierer die zur Verfügung stehenden auch kennen, und nicht darauf angewiesen sein, sie durch Zufall zu entdecken.

Mir erschließt sich der konkrete Nutzen immer noch nicht - vielleicht deshalb, weil du immer noch nicht konkret gesagt hast, was du damit tun willst.

Du musst es mir natürlich nicht erklären, nur kann ich dir dann wohl auch nicht helfen.

Grüße,

RIDER