MySQL Anbindung Options

[hotti]

hi,

meine Anbindung mache ich mit mysqli_init(); das hat den Vorteil, dass ein Timeout gesetzt werden kann:

  
function dbase(){  
	global $cfg;  
	  
	$db = mysqli_init();  
	$db->options(MYSQLI_OPT_CONNECT_TIMEOUT, 3);  
		  
	$db->real_connect($cfg['mysql']['host'], $cfg['mysql']['user'], $cfg['mysql']['pass'], $cfg['mysql']['base']);  
	  
	  
	if (mysqli_connect_errno()) return;  
	else return($db);  
}  

Der Timeout greift, was mich freut, was mich nicht so freut, es gibt noch Warnmeldungen. Wie kann ich diese ausschalten? Also nicht generell, sondern nur für Mysql. Habs nicht gefunden in der Doku, bitte helft mir mal beim Suchen.

Viele Grüße,
Horst Ohrenschmalz

[ChrisB]

Hi,

$db->options(MYSQLI_OPT_CONNECT_TIMEOUT, 3);

$db->real_connect($cfg['mysql']['host'], $cfg['mysql']['user'], $cfg['mysql']['pass'], $cfg['mysql']['base']);

Der Timeout greift, was mich freut, was mich nicht so freut, es gibt noch Warnmeldungen. Wie kann ich diese ausschalten? Also nicht generell, sondern nur für Mysql.

Du kannst den error control operator nutzen.
(Was man aber generell sparsam tun sollte, denn was der macht, ist bei jeder Verwendung das error_reporting-Level herab- und anschliessend sofort wieder auf den zuvor eingestellten Wert heraufzusetzen.)

MfG ChrisB

[dedlfix]

Hi!

es gibt noch Warnmeldungen. Wie kann ich diese ausschalten?

Solange du dir bewusst bist, dass du Fehlermeldungen unterdrückst und auch entsprechende Maßnahmen zum Anfangen von Fehlerzuständen ergriffen hast (sprich: vor allem Funktionsrückgabewerte ausgewertet hast), spricht nicht mehr viel gegen die Verwendung des Fehlermeldungsunterdrückungsoperators.

Im Produktivbetrieb sollte sowieso display_errors ausgeschaltet sein. Es empfiehlt sich jedoch, die auftretenden Fehler anderswo mitzuschreiben und gelegentlich auszuwerten, wenn einem die Gesundheit der Anwendung lieb ist.

Lo!

[hotti]

hi,

Solange du dir bewusst bist, dass du Fehlermeldungen unterdrückst und auch entsprechende Maßnahmen zum Anfangen von Fehlerzuständen ergriffen hast (sprich: vor allem Funktionsrückgabewerte ausgewertet hast), spricht nicht mehr viel gegen die Verwendung des Fehlermeldungsunterdrückungsoperators.

den kenn ich bereits, der geht ja auch in der Variante mit @new... Aber wo tu ich den jetzt hin bei

$db->real_connect(); // ?

Im Produktivbetrieb sollte sowieso display_errors ausgeschaltet sein.

Das ist schonmal eine gute Aussage gegenüber denen, die immer lapidar sagen, dass "man Fehlermeldungen nicht ausschalten sollte" ;-)

Klar, Besucher brauchen keine Warnungen oder Fehlermeldungen, die sollen nur sehen obs geht oder (gradmal) nicht geht.

Viele Grüße,
Horst

[dedlfix]

Hi!

den kenn ich bereits, der geht ja auch in der Variante mit @new... Aber wo tu ich den jetzt hin bei
$db->real_connect(); // ?

Wenn das die Funktion ist, die den Timeout meldet, dann kommt er davor.

Im Produktivbetrieb sollte sowieso display_errors ausgeschaltet sein.
Das ist schonmal eine gute Aussage gegenüber denen, die immer lapidar sagen, dass "man Fehlermeldungen nicht ausschalten sollte" ;-)
Klar, Besucher brauchen keine Warnungen oder Fehlermeldungen, die sollen nur sehen obs geht oder (gradmal) nicht geht.

Vom System erzeugte Fehlermeldungen sind etwas für den der das System betreut. Üblicherweise können die Besucher nichts für den auftretenden Fehler, sie können ihn auch nicht reparieren, also nützt ihnen auch die Meldung nichts. Im Gegenteil, diejenigen, die sie verstehen könnten das dabei gewonnene Wissen gegen die Anwendung einsetzen. Wenn der Besucher Meldungen vorgesetzt bekommt, sollten sie ihm insofern von Nutzen sein, als dass sie doch noch irgendwie zu ihrem Ziel kommen.

Lo!

[hotti]

hi,

Vom System erzeugte Fehlermeldungen sind etwas für den der das System betreut. Üblicherweise können die Besucher nichts für den auftretenden Fehler, sie können ihn auch nicht reparieren, also nützt ihnen auch die Meldung nichts. Im Gegenteil, diejenigen, die sie verstehen könnten das dabei gewonnene Wissen gegen die Anwendung einsetzen. Wenn der Besucher Meldungen vorgesetzt bekommt, sollten sie ihm insofern von Nutzen sein, als dass sie doch noch irgendwie zu ihrem Ziel kommen.

Full Ack!!!

Danke auch an ChrisB,
viele Grüße an Alle,
Horstilein

[ChrisB]

Hi,

Im Produktivbetrieb sollte sowieso display_errors ausgeschaltet sein.

Das ist schonmal eine gute Aussage gegenüber denen, die immer lapidar sagen, dass "man Fehlermeldungen nicht ausschalten sollte" ;-)

Hier ist zu unterscheiden dazwischen, ob man von PHP gar nichts hören will (error_reporting auf 0 stellen), oder ob man eben nur die Anzeige von Fehlermeldungen in der Ausgabe unterbindet.

MfG ChrisB

[hotti]

hi,

Hier ist zu unterscheiden dazwischen, ob man von PHP gar nichts hören will (error_reporting auf 0 stellen), oder ob man eben nur die Anzeige von Fehlermeldungen in der Ausgabe unterbindet.

Ja, da hast du schon recht. Auf jeden Fall, solange ich noch am Lernen von PHP bin, nehme _ich_ erst einmal jede Fehler|Warnmeldung mit, damit ich kapiere, wie PHP überhaupt arbeitet. Von Perl her kommend (auch perl -w), ist es ein bischen aufwendiger, ein PHP-Script frei von Warnmeldungen zu kriegen und wenn ich das hab, muss ich auch keine Warnungen ausschalten.

Nur bei der MySQL DB Anbindung sehe ich das ein bischen Anders.... obwohl: Es kommt (hoffentlich) selten vor, dass der DB Server weg ist und wenn, ists eh egal mit der Warnmeldung denke ich jetzt.

Vieße Grüle,
Rolf

[Tom]

Hello,

Ja, da hast du schon recht. Auf jeden Fall, solange ich noch am Lernen von PHP bin, nehme _ich_ erst einmal jede Fehler|Warnmeldung mit, damit ich kapiere, wie PHP überhaupt arbeitet. Von Perl her kommend (auch perl -w), ist es ein bischen aufwendiger, ein PHP-Script frei von Warnmeldungen zu kriegen und wenn ich das hab, muss ich auch keine Warnungen ausschalten.

Da irrt der Statement-Hotti aber!

Man sollte unterscheiden zwischen Meldungen, die der Parser aufgrund von Syntaxfehlern erzeugt. Die sollten ausgemerzt werden und dann ist da auch nix mehr auszuschalten...

Meldungen, die wegen logischer Programmierfehler erzeugt werden, kannst Du zwar nachher auch ausschalten, aber da man das nie genau weiß, ob man sie alle vernichtet hat, weil ja PHP bei bedingten Statements oft erst auf den Fehler läuft, wenn der bedingte Zweig auch abgearbeitet wird, sollte man diese Meldungsgruppe schon mal auffangen.

Und dann gibt es Laufzeitmeldungen, die der Interpreter produziert, weil der vermutete Zustand nicht vorliegt oder sogar gerade deshalb, _weil_ er vorliegt. Diese Laufzeitmeldungen musst Du behandeln und die eigentliche Meldung dann irgendwie unterdrücken oder umleiten, wenn sie nicht behandelbar war.

Ggf. musst Du dann sogar noch eine zusätzliche Exception/Fehlerstrategie einfügen, wenn eine Laufzeitreaktion nicht behandelbar ist.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

Hello,

Ja, da hast du schon recht. Auf jeden Fall, solange ich noch am Lernen von PHP bin, nehme _ich_ erst einmal jede Fehler|Warnmeldung mit, damit ich kapiere, wie PHP überhaupt arbeitet. Von Perl her kommend (auch perl -w), ist es ein bischen aufwendiger, ein PHP-Script frei von Warnmeldungen zu kriegen und wenn ich das hab, muss ich auch keine Warnungen ausschalten.

Da irrt der Statement-Hotti aber!

soso ;-)

Nurmal so nebenbei lieber Tom: ich bins gewohnt mit perl -w zu entwickeln. Da schreibe ich gerne malne Zeile mehr, damit die Platte mit dem error_log nicht schmilzt.

MfG,
Horst Wierfülspiltz