MYSQL Datenbank unter 5.5 ODer Umstellung auf mysqli

[Max]

Bis zur Umstellung auf PHP 5.5 habe ich das so bewerkstelligt:

$Verbindung = mysql_connect(DB_HOST,DB_USER,DB_PASSWORD) or die ("Verbindung fehlgeschlagen");
mysql_select_db(DB_NAME);

nun gibts diese Fehlermeldung:

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead i

Ok ich ich kann Sie abschalten.... aber dann...

Also gut, ich hab versucht sie duch das suchem im www zu lösen. Ansatzweise habe ich auch eine Lösung:

$Verbindung = mysqli_connect(DB_HOST,DB_USER,DB_PASSWORD,DB_NAME);

aber jetzt.....

heisst das das ich alle Datenbankbefehle innerhalb meiner Scripte anpassen muss.

also aus:

$alt = mysql_query($SQLString)

muss ich dann:

$neu = mysqli_query($Verbindung, $SQLString)

machen..????

Wahrscheinlich schon, was ja viel Arbeit bedeutet...

Max

[M.]

Mahlzeit,

Wahrscheinlich schon, was ja viel Arbeit bedeutet...

grundsätzlich ist mysql und mysqli grundverschieden, eine Änderung ist individuell und kostet Zeit.
Allerdings ist das schon länger als 2 Wochen bekannt, dass mysql wegfällt. Ich kapiert nicht, wieso die Scripter nicht nach und nach den Code anpassen, immerhin wird doch ein Script zwangsläufig ständig weiterentwickelt, sondern bis zum Schluss warten und dann anfangen zu jammern.

Die andere Seite sind Entwickler, die ein neues Projekt auf mysql aufbauen, anstatt gleich auf mysqli (oder PDO) zu setzen.

Kurz gesagt: Ja, du hast viel Arbeit. Pauschalaussagen wie du ändern musst, sind unmöglich zu treffen, da musst du die Doku lesen ;) Deine Ansätze stimmen aber erstmal :)

[MAX]

Also, das ist ja dann doch ein wneig arbeit!

Kann ich diese Fehlermeldung abschalten. Ich meine nicht alle nur die eine:

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in...

Max

[Max]

Ich habs jetzt so gelöst:

error_reporting(0);
...
Datenbankanbindung
...
error_reporting(E_ALL);

[M.]

Mahlzeit,

Ich habs jetzt so gelöst:

error_reporting(0);
...
Datenbankanbindung
...
error_reporting(E_ALL);

Und bei Datenbank-Abfragen machst du das genauso?

[Tom]

Hello,

Kann ich diese Fehlermeldung abschalten. Ich meine nicht alle nur die eine:

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in...

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

  
$con = @mysql_connect(HOST, USER, PASS);  
  
if (!is_resource($con))  
{  
    ## Fehlerbehandlung  
    ## ...  
}  
  

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Max]

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

Ja sollte ich eine eigene Fehlerbehandlung betreiben? Wenn ja, warum? hilft sie mir weiter?

Max, der der viel Wissen will

[Tom]

Hello,

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

Ja sollte ich eine eigene Fehlerbehandlung betreiben?

JA!

Wenn ja, warum? hilft sie mir weiter?

* stabilere Applikationen
* zufriedenere Benutzer
* konsistent(er)e Daten

Das sollte eigentlich schon genügen, aber die Anderen finden bestimmt noch mehr Gründe.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

Ja sollte ich eine eigene Fehlerbehandlung betreiben?

Wenn dir kein akuter Grund vorliegt, dann nicht. Im schlimmsten Fall schadet man sich selbst damit mehr als man gut machen kann.

Und wenn doch, dann sollte man on-top etwas bauen und nicht gegen die bestehenden Sicherheitsmechanismen arbeiten.

Der @-Operator ist ein Parade-Beispiel. Man unterdrückt damit nämlich nicht nur die Fehlermeldung, sondern auch die Fehler-Berichterstattung. Das heißt es wird nicht nur die Frontend-Ausgabe des Fehlers unterdrückt, sondern zum Beispiel auch das Logging des Fehlers. Der eigene Custom-Handler wird zwar trotzdem aufgerufen, aber das Logging ist verloren.

Auch mit try/catch kann man sich sehr schnell in eine Sackgasse manövrieren. In fast 100% der Fälle sehe ich folgendes Konstrukt:

try { … } catch ( Exception $e ) { … }

Das Problem mit diesem Code ist, dass er einfach jede Exception abfängt und nicht nur spezifische Subclassen von Exception. In den meisten Fällen bezieht sich so ein try-Block nämlich auf ein paar wenige Zeilen, die ganz konkrete Fehler werfen, imho. sollte man sich dann im Catch-Block auch genau darauf beziehen.

Bevor man anfängt willkürlich irgendwelche Custom-Error-Handler zu registrieren, sollte man sich erstmal mit den bestehenden Möglichkeiten auseinander setzen und meiner Meinung nach sollte man immer auf das bewährte und erprobte native Fehlersystem setzen, wenn es geht. Nur wenn dann noch Wünsche offen bleiben, sollte man sich Gedanken um eine Erweiterung machen. Das wäre zum Beispiel der Fall, wenn man bei bestimmten kritischen Fehlern eine Email erhalten möchte. Dafür gibt es in PHP keine Standard-Direktive, da würde sich eine eigene Behandlungs-Routine lohnen.

[Tom]

Hello,

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

Ja sollte ich eine eigene Fehlerbehandlung betreiben?

Wenn dir kein akuter Grund vorliegt, dann nicht. Im schlimmsten Fall schadet man sich selbst damit mehr als man gut machen kann.

Diese lästige Diskussion hatten wir hier schon einmal.
Wenn der Fehler ein voraussehbarer Laufzeitfehler ist, muss er auch behandeltwerden, da er den weiteren Verlauf des Programmes beeinflusst.

Es hat meistens wenig Sinn, das Script normal weiterlaufen zu lassen, wenn keine Datenbankverbindung zustande gekommen ist. Entweder kann man dies z.B. durch nochmaligen Versuch beheben, oder das Script muss dem User eine entsprechende Alternative anbieten.

Es ist mMn aber sinnlos, dem User eine technische Fehlermeldung auf den Schrim zu schreiben und dann weiterzumachen. Und wenn der Fehler nicht reparierbar war, muss im Script an dieser Stelle eien passende Meldung ins Log für den Administrator/Entwickler und eine liebevoll gestaltete Entschuldigungsseite mit Links für Alternativen für den User auf die Standardausgabe.

Dass man Fehler, deren Meldungen man unterdrückt, selber behandeln muss, habe ich mMn deutlich gesagt. Dass zur Fehlerbehandlung mehrere Schritte gehören, können wir jetzt behandeln, wenn es den wissenshungrigen Max interessiert.

* Fehler identifizieren
* ist der Fehler heilbar?

• ja: nochmal versuchen, ein Logging kommt nur selten in Betracht
  ---> weiter im Script

• nein:
  * Logging für den Admin
  * kann man dem User eine Alternative anbieten?

• ja: Altgernative anbieten und weiter

• nein: hier wird es erst wirklich interessant!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Auge]

Hallo

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

Ja sollte ich eine eigene Fehlerbehandlung betreiben?

Wenn dir kein akuter Grund vorliegt, dann nicht. Im schlimmsten Fall schadet man sich selbst damit mehr als man gut machen kann.

Diese lästige Diskussion hatten wir hier schon einmal.
Wenn der Fehler ein voraussehbarer Laufzeitfehler ist, muss er auch behandeltwerden, da er den weiteren Verlauf des Programmes beeinflusst.

Nichts von dem, was du in deinem Posting im weiteren Text beschreibst, widerspricht dem von 1UnitedPower geschriebenen. Wo er dir, meiner Meinung nach zu Recht, widerspricht, ist deine Aussage, man solle eine eigene Fehlerbehandlung einbauen.

Die meisten Leute, die ja typischerweise eine PHP-Anwendung aus anderer Hand betreiben oder mit PHP einzelne zusätzliche Funktionen in ihre Seiten einbauen, haben keinen blassen Schimmer von der programmierung einer eigenen Fehlerbehandlung. Die würden dabei im schlimmsten Fall ihren Skripten weitere Fehler hinzufügen, ohne auf bereits vorhandene hingewiesen zu werden.

Da ist es mir lieber, hier immer wieder „Schalte das Error-Reporting und die Anzeige ein!“ zu lesen und mit den „Warum steht da …?“-Fragen und den „Das steht doch da!“-Antworten im Forum zu leben. Und bestenfalls lernt der Fragensteller dabei, wie er vorausschauend programmiert und kann hinterher kompetent mit etwaigen Fehlern umgehen und selbst die lästigen „Das steht doch da!“-Antworten übernehmen (Geteilte Last ist schließlich halbe Last).

Tschö, Auge

[Tom]

Hello,

Nichts von dem, was du in deinem Posting im weiteren Text beschreibst, widerspricht dem von 1UnitedPower geschriebenen. Wo er dir, meiner Meinung nach zu Recht, widerspricht, ist deine Aussage, man solle eine eigene Fehlerbehandlung einbauen.

Wie kann man denn ohne eigene Fehlerbehandlung feststellen, dass ein Fehler aufgetreten ist?

Wenn ich die automatische Fehlerbehandlung von PHP laufen lasse, bekomme ich die Meldungen, je nach Einstellung auf den Schirm oder nur ins Log, aber der Fehler ist dadurch nicht behoben.

Du wirst hier im Archiv 10.000de von Threads finden, in denen der OP gefragt wird, wo er denn seine Fehlerbehandlung gelassen hat. Wer seine Formulierungen und sein Verständnis für PHP-Programmierung überprüfen muss, bin also nicht ich, sondern sind 1UnitedPower und Du. Im ersten Moment schoss mir da ja durch den Kopf "Scheiße, brauch ich jetzt einen Rechtsanwalt, um meine Texte für das Forum formulieren zu lassen?" :-P

ICH kann mir zwar denken, auf was Ihr beide anspielt, aber das solltet Ihr dann auch klarer formulieren für Max, damit er nicht verwirrt wird.

Den Erfolg seines MySQL-Statements sollte er aber auf jeden Fall kontrollieren und das nennt man dann "Fehlerbehandlung".

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Den Erfolg seines MySQL-Statements sollte er aber auf jeden Fall kontrollieren und das nennt man dann "Fehlerbehandlung".

Nein, das nennt man "Fehlerprüfung". Damit ist er noch lange nicht behandelt.

[Tom]

Hello,

Den Erfolg seines MySQL-Statements sollte er aber auf jeden Fall kontrollieren und das nennt man dann "Fehlerbehandlung".

Nein, das nennt man "Fehlerprüfung". Damit ist er noch lange nicht behandelt.

Also doch einen Rechtsanwalt.

Hat der Clown geschmeckt?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Also doch einen Rechtsanwalt.

Hat der Clown geschmeckt?

Fehlerprüfung:

  
$success = $db->getData();  

Fehlerbehandlung:

  
if($success == FALSE) echo "Fehler";  

Wenn das für dich "Clown gefrühstückt" ist, muss ich, wieder mal, an deinem Fachwissen zweifeln.

[Tom]

Hello,

Also doch einen Rechtsanwalt.

Hat der Clown geschmeckt?

Na dann mal von vorne:

Das Ganze nennt man Fehlerbehandlung. Die Fehlerbehandlung besteht aus
* Fehlerprüfung
* Fehlermeldung
* Fehlerbeseitigung

Fehlerprüfung:

$success = $db->getData();

  
Das ist keine Fehlerprüfung, sondern nur die Zuwweisung eines Wertes an eine Variable.  
  
  

> Fehlerbehandlung:  
> ~~~php
  

> if($success == FALSE) echo "Fehler";  
> 

Das ist zwar schon ein Teil einer Fehlerbehandlung, nämlich die Prüfung (durch den Vergleich) und eine Fehlermeldung, auch wenn die hier plump auf die Standardausgabe geht. Ob die anderswo umgebogen wurde, kann ich nicht erkennen.

Es fehlt also der wichtigste Teil: die Fehlerbeseitigung

Wenn das für dich "Clown gefrühstückt" ist, muss ich, wieder mal, an deinem Fachwissen zweifeln.

Dank, ich bin zufrieden mit meinem Fachwissen und meine beiden Kollegen grinsen auch gerade mächtig über dein Posting.

Ich muss jetzt erstmal weiterarbeiten. Bis später dann.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[M.]

Mahlzeit,

Dank, ich bin zufrieden mit meinem Fachwissen und meine beiden Kollegen grinsen auch gerade mächtig über dein Posting.

Dann zeig ihnen doch _deine_ Postings, dann kriegen sie sich nicht mehr ein.

[Tom]

Hello,

Dank, ich bin zufrieden mit meinem Fachwissen und meine beiden Kollegen grinsen auch gerade mächtig über dein Posting.

Dann zeig ihnen doch _deine_ Postings, dann kriegen sie sich nicht mehr ein.

Mach ich. Spaß im Büro gehört bei uns dazu.

Du bist ihnen sowieso zu negativ eingestellt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Auge]

Hallo

Nichts von dem, was du in deinem Posting im weiteren Text beschreibst, widerspricht dem von 1UnitedPower geschriebenen. Wo er dir, meiner Meinung nach zu Recht, widerspricht, ist deine Aussage, man solle eine eigene Fehlerbehandlung einbauen.

Wie kann man denn ohne eigene Fehlerbehandlung feststellen, dass ein Fehler aufgetreten ist?

Indem man Systemmeldungen liest, auswertet und die Fehler behebt?

Wenn ich die automatische Fehlerbehandlung von PHP laufen lasse, bekomme ich die Meldungen, je nach Einstellung auf den Schirm oder nur ins Log, aber der Fehler ist dadurch nicht behoben.

s.o.

Du wirst hier im Archiv 10.000de von Threads finden, in denen der OP gefragt wird, wo er denn seine Fehlerbehandlung gelassen hat.

Das würde ich auf eine Wette ankommen lassen. Mir ist diese Frage von Threaderstellern gefühlt nie untergekommen. Ja, als Gegenfrage von Antwortenden schon, aber nicht von den Stellern der Ursprungsfrage.

Wer seine Formulierungen und sein Verständnis für PHP-Programmierung überprüfen muss, bin also nicht ich, sondern sind 1UnitedPower und Du.

Wenn du meinst …

ICH kann mir zwar denken, auf was Ihr beide anspielt, aber das solltet Ihr dann auch klarer formulieren für Max, damit er nicht verwirrt wird.

Ich kann für mich sagen: Ich habe für dich und nicht für Max formuliert.

Den Erfolg seines MySQL-Statements sollte er aber auf jeden Fall kontrollieren und das nennt man dann "Fehlerbehandlung".

Natürlich, aber das sollte man als Anfänger, der Max offensichtlich ist, am Beispiel erlernen und nicht etwas Vorgefertigtes nehmen, das weit hinter dem eigenen Horizont liegt. Nun gehört dein Beispiel nicht in diese Kategorie, aber 1UnitedPowers Punkt mit der durch das @ unterdrückten Systemmeldung bleibt. Mit der Systemmeldung lässt sich mit an Sicherheit grenzender Wahrscheinlichkiet in der Suchmaschine der eigenen Wahl etwas braquchbares ermitteln. Mit der eigenen, eventuell unverstandenen Fehlerroutine nicht.

Deshalb unterstütze ich seine Aussage, statt der eigenen Fehlerbehandlung zuvörderst die von PHP bereitgestellten Mittel zu nutzen.

Tschö, Auge

[1UnitedPower]

Meine Herren!

Wenn der Fehler ein voraussehbarer Laufzeitfehler ist, muss er auch behandeltwerden, da er den weiteren Verlauf des Programmes beeinflusst.

Du hast mein Posting offenbar nicht genau genug gelesen oder du hast es nicht verstanden. Ich wollte nicht diskutieren, ob Fehler- und Ausnahmen überhaupt behandelt werden sollen oder nicht, ich wollte nur darauf, dass man das MIT oder GEGEN die Sicherheitsmechanismen von PHP tun kann. Deine bisherigen Antworten haben mir gezeigt, dass deine Sicht etwas verkürzt und dass du die momentan dagegen arbeitest.

Ich möchte das mal ganz konkret an deinem eigenen Beispiel erläutern:

$con = @mysql_connect(HOST, USER, PASS);

if (!is_resource($con))

  
Die angesprochene deprecated-Warnung wird dadurch nicht behoben sondern unterdrückt! Und lass uns doch mal den Fall analysieren, dass in einer späteren PHP-Version die mysql\_-Funktionen gestrichen werden, was würde dein Code dann machen? Er würde einfach abbrechen. Er würde nicht mal bis zu der if-Verzweigung gelangen. Ein Funktionsaufruf einer nicht vorhanden Funktion ist ein Fatal-Error, der von dem @-Operator nicht unterdrückt werden kann.  
  
Das Problem ist, dass du schon den Fehler (trotz aussagekräftiger Meldung) nicht richtig identifiziert hast. Du hast einen Folgefehler (keine Datenbank-Verbindung) identifiziert!  
  
Dass du auf diese Weise GEGEN und nicht MIT PHP-Fehlerbehandlung arbeitest, zeigt sich sprachlich auch sehr gut in diesem Satz von dir:  
  

> Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die > Ausgabe der Meldung unterdrücken  
  
Und das habe ich versucht richtig zu stellen. Fehlerbehandlung muss sein, aber richtig. So wie deine Aussage da stand, war sie fahrlässig und gefährlich.  

-- 
“All right, then, I'll go to hell.” – Huck Finn

[Tom]

Hello 1UP,

ich nehm das Geschriebene jetzt mal teilweise zurück und behaupte nicht das Gegenteil, sondern gebe Dir gerne (was Deine Erkenntnisse betrifft) teilweise Recht. Was allerdings PHP betrifft, gebe ich nur ungerne zu, dass Du teilweise Recht hast, denn das Konzept wird dadurch immer wackeliger und undurchsichtiger.

Anstelle des @ vor dem jeweiligen Funktionsaufruf sollte man also besser

  
ini_set('display_errors', 0);  
  
[code]  
  
benutzen. Das hat zur Folge, dass alle Fehler, die mit  
  
[code lang=php]  
error_reporting($wert);  
  
[code]  
festgelegt wurden, weiterhin im PHP-ERROR-LOG [1] registriert werden und trotzdem die diskrete Fehlerauswertung/Behandlung mit  
  
if( ... )  
{  
     $_error = error_get_last();  
  
     # ....  
  
}  
  

möglich ist, wenn keine anderen Verbiegungen des Fehlersystems vorgenommen wurden.

Fatal Errors sorgen so zwar auch zum Abbruch des Scriptes, werden aber im PHP-ERROR-LOG [1] registriert.

[1] Das PHP Error Log ist nicht identisch mit dem Webserver-Error-Log. Es lässt sich aber dorthin umlenken. Wenn also z.B. im Apache-Error-Log keine PHP-Fehler landen, heißt das nicht, dass diese nicht im PHP-Error-Log registriert wurden.

Wenn wir Drei hier ein wenig aufgeräumt haben in den durch Dich vermittelten neuen Einsichten, werde ich das vielleicht wirklich mal ansatzweise in einen Wiki-Artikel fließen lassen, der dann zur ständigen Vervollständigung bereit stehen wird. Obn da vorher 'was Qualifiziertes von Sven kommt, bleibt abzuwarten :-P

Da spielen ja diverse Effekte und Tricks mit (unter anderem auch register_shutdown_function()) und wie man sich _schrittweise_ von der Standard-Fehlerbehandlung lösen kann, ist mMn einen Artikel wert.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Wenn wir Drei hier ein wenig aufgeräumt haben

Wo besteht denn für dich noch Aufräumbedarf? Nur Mut zur Frage ;)

Den meisten Aussagen im Thread kann ich inzwischen zustimmen. Dem Rest habe ich widersprochen.

Die einzig wahre Lösung zu der thematisierten deprecated-Warnung ist, die mysql_-API durch einen zeitgenössischen Kandidaten zu ersetzen. Das hat Auge schon sehr früh deutlich gemacht. Alles andere ist keine echte Lösung zu diesem Problem.

Man kann sich natürlich auch bewusst dazu entscheiden, den Fehler nicht zu beheben. Oder man kann sich bewusst dazu entscheiden, die Augen vor dem Fehler zu verschließen. Dann sollte das aber im Projekt idealerweise dokumentiert werden.

Da spielen ja diverse Effekte und Tricks mit (unter anderem auch register_shutdown_function()) und wie man sich _schrittweise_ von der Standard-Fehlerbehandlung lösen kann, ist mMn einen Artikel wert.

Fehlerbehandlung muss auf allen Software-Schichten und aus unterschiedlichen Perspektiven auf verschiedene Facetten betrieben werden. Es wird dir nicht gelingen diese Facetten zu abstrahieren und dich von den PHP-Mechanismen zu entkoppeln. Und ich halte das auch nicht für erstrebenswert. Die bekannten Fallstricke, von denen ich jetzt schon ein paar aufgezählt habe, sind von der Szene gut diskutiert und dokumentiert, es sind Konventionen gefunden wurden damit umzugehen. Eine dieser Konventionen ist übrigens auch, dass man kognitive Abweichungen dokumentieren sollte.

[Sven Rautenberg]

Moin!

Anstelle des @ vor dem jeweiligen Funktionsaufruf sollte man also besser

ini_set('display_errors', 0);

>   
> benutzen.  
  
"Sollte" man eher nicht, weil: Warum? In produktiven Systemen wird der Wert sowieso auf 0 gesetzt worden sein, zumindest in gut konfigurierten. In Testsystemen wird der Wert ggf. absichlich nicht auf 0 stehen, und man will die Fehler sehen.  
  
Und das Setzen auf 0 führt dann zu dem Problem, dass man es hinterher wieder auf den Wert zurücksetzen muss, der vorher da war. "ini\_set()" gibt den alten Wert zurück - oder false bei Fehlern. Also brauchts eigentlich schon wieder eine Fallunterscheidung auf "Fehler beim ini\_set()" vs. "ini\_set hat echtes false als alten Wert zurückgegeben (vermutlich ist das aber auf Integer-Values gewandelt worden)"...  
  
Die Sache wird dadurch also alles andere als einfacher, sondern komplexer. Ich will als Programmierer solchen komplexen Code aber nicht haben, ich will einfachen Code. Die Komplexität kommt schon von ganz allein durch die eigentliche Aufgabe rein. (Pro-Tipp: Exceptions helfen dabei.)  
  
 - Sven Rautenberg

[Tom]

Hello,

Anstelle des @ vor dem jeweiligen Funktionsaufruf sollte man also besser

ini_set('display_errors', 0);

> >   
> > benutzen.  
>   
> "Sollte" man eher nicht, weil: Warum? In produktiven Systemen wird der Wert sowieso auf 0 gesetzt worden sein, zumindest in gut konfigurierten. In Testsystemen wird der Wert ggf. absichlich nicht auf 0 stehen, und man will die Fehler sehen.  
  
[blubb, blubb, blubb]  
  
Ging es nicht um eine professionelle Behandlung im Produktivsystem?  
Da ist @ dann falsch.  
Und im Testsystem ist auch immer noch nicht festgelegt, ob´man nicht nebenbei auf einer Fehlerkonsole schaut, was da so an Problmenen kommt.  
  
Irgendwie komme ich mir hier inzwischen voe, wie in einem Alzheimerforum. Schließe mich da selber nicht aus, aber auch DU, Sven, hast schon bessere Ratschläge gegeben!  
  
  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
[Die ultimative Seite für Selbermacher](http://getscript.de/)

[1UnitedPower]

Meine Herren!

Wenn der Fehler ein voraussehbarer Laufzeitfehler ist, muss er auch behandeltwerden, da er den weiteren Verlauf des Programmes beeinflusst.

Du hast mein Posting offenbar nicht genau genug gelesen oder du hast es nicht verstanden. Ich wollte nicht diskutieren, ob Fehler- und Ausnahmen überhaupt behandelt werden sollen oder nicht. Ich wollte nur darauf hinaus, dass man das MIT oder GEGEN die Sicherheitsmechanismen von PHP tun kann. Deine bisherigen Antworten haben mir gezeigt, dass deine Sicht etwas verkürzt ist und dass du momentan noch dagegen arbeitest.

Ich möchte das mal ganz konkret an deinem eigenen Beispiel erläutern:

$con = @mysql_connect(HOST, USER, PASS);

if (!is_resource($con))

  
Die angesprochene deprecated-Warnung wird dadurch nicht behoben sondern unterdrückt! Und lass uns doch mal den Fall analysieren, dass in einer späteren PHP-Version die mysql\_-Funktionen gestrichen werden, was würde dein Code dann machen? Er würde einfach abbrechen. Er würde nicht mal bis zu der if-Verzweigung gelangen. Ein Funktionsaufruf einer nicht vorhandenen Funktion ist ein Fatal-Error, der von dem @-Operator nicht unterdrückt werden kann.  
  
Das Problem ist, dass du schon den Fehler (trotz aussagekräftiger Meldung) nicht richtig identifiziert hast. Du hast einen Folgefehler (keine Datenbank-Verbindung) identifiziert!  
  
Dass du auf diese Weise GEGEN und nicht MIT PHP-Fehlerbehandlung arbeitest, zeigt sich sprachlich auch sehr gut in diesem Satz von dir:  
  

> Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die  
> Ausgabe der Meldung unterdrücken  
  
Und das habe ich versucht richtig zu stellen. Fehlerbehandlung muss sein, aber richtig. So wie deine Aussage da stand, war sie fahrlässig und gefährlich.

-- 
“All right, then, I'll go to hell.” – Huck Finn

[Sven Rautenberg]

Moin!

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

$con = @mysql_connect(HOST, USER, PASS);

if (!is_resource($con))
{
    ## Fehlerbehandlung
    ## ...
}

  
Die Fehlererkennung durch das "@"-Zeichen abzuschalten kostet Performance und verhindert Debugging, weil an dieser Stelle keinerlei Fehlermeldung mehr irgendwo landet, auch nicht im Logfile der Produktivumgebung.  
  
Sowas sollte man niemals tun, und erst recht nicht Anfängern in Foren raten. Vor allem, wenn der eigentliche Punkt "eigene Fehlerbehandlung" dann nur mit dem Code-Kommentar "## Fehlerbehandlung" ausgefüllt wird, aber nicht mit einem funktionierenden, illustrierenden Beispiel deiner eigenen Fehlerbehandlung.  
  
Gute Fehlerbehandlung nutzt evtl. ["set_error_handler()"](http://de2.php.net/manual/de/function.set-error-handler.php), man kann damit auch das [Werfen von ErrorExceptions](http://de2.php.net/manual/de/class.errorexception.php) konfigurieren, und das [Behandeln von ungefangenen Exceptions](http://de2.php.net/manual/de/function.set-exception-handler.php) gibts auch.  
  
 - Sven Rautenberg

[Tom]

Hello,

Da Du doch sowieso eine eigene Fehlerbehandlung betreiben solltest, kannst Du die Ausgabe der Meldung unterdrücken

$con = @mysql_connect(HOST, USER, PASS);

if (!is_resource($con))
{
    ## Fehlerbehandlung
    ## ...
}

  

> Gute Fehlerbehandlung nutzt evtl. ["set_error_handler()"](http://de2.php.net/manual/de/function.set-error-handler.php),  
  
Das ist jetzt für das Behandeln einer Fehlerquelle reichlich überskaliert und garantiert nichts für einen Anfänger! Und ich vermute, dass uns genau das 1UnitedPower auch sagen wollte mit seiner Bemerkung  
  
try { … } catch ( Exception $e ) { … }  
  
Die Fehlerbehandlung komplett aus dem System herauszunehmen erfordert sehr viel Wissen über PHPs Interna. Hier ging es nur über die eigene Fehlerbehandlung des MySQL-Statements!  
  
Und da ist es legitim, die automatische Fehlerbehandlung FÜR DIESES EINE STATEMENT auszuschalten, wenn man sie denn selber übernimmt. Und wenn Du meinst, dass man hier jetzt unaufgefordert einen ausführlichen Fachvortrag über den Körper der Bedingung der Fehlerprüfung oder sogar den Aufbau von fehlertoleranten Systemen halten sollte, will ich Dich nicht daran hindern.  
  
Dies war bisher vom OP nicht gefordert worden.  
  
Wäre aber eine gute Idee, wenn Du dein Fachwissen zum Thema da mal im Wiki unterbringen würdest. Das würde Allen etwas nützen :-)  
  
  
  
  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
[Die ultimative Seite für Selbermacher](http://getscript.de/)

[dedlfix]

Tach!

Kann ich diese Fehlermeldung abschalten. Ich meine nicht alle nur die eine:
Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in...

Wenn dich generell keine Deprecated-Meldungen interessieren, dann setz doch das error_reporting auf E_ALL & ~E_DEPRECATED

dedlfix.

[Auge]

Hallo

Bis zur Umstellung auf PHP 5.5 habe ich das so bewerkstelligt:

$Verbindung = mysql_connect(DB_HOST,DB_USER,DB_PASSWORD) or die ("Verbindung fehlgeschlagen");
mysql_select_db(DB_NAME);

nun gibts diese Fehlermeldung:

Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead i

Ok ich ich kann Sie abschalten.... aber dann...

Bevor es zu Missinterpretationen kommt. Die Meldung besagt, dass die mysql_*-Funktionen missbilligt sind und in der Zukunft, genauer: in einer zukünftigen PHP-Version, wegfallen werden. Du musst nichts abschalten.
Du musst über kurz oder lang auf eine der anderen MySQL-Zugriffsarten (MySQLi, PDO) umstellen.

Fange zeitnah an, damit du zeitnah fertig wirst und es nicht dringend werden muss.

Tschö, Auge