[php] [mysql] $link->query() fouten opvangen

[Redsandro]

Pseudocode om een foute query op te vangen:

mysql_query() or die()

if (!mysql_query()) {}

Hoe doe je zoiets oo?

code:

$link = new mysqli()
$link->query()

Want wat ik ook doe, bij een foute query stopt mijn localhost er mee zonder output. Wit scherm.

Werkt niet:

code:

$link->query() or die()

code:

if (!$foo = @$link->query())

code:

try {
    $link->query()
} catch {}

Ik kan niets vangen.

[Avalaxy]

Ik heb geen ervaring met MySQLi (wel met PDO), maar op PHP.net vind ik dit:

PHP:

<?php
$mysqli = new mysqli("localhost", "my_user", "my_password", "world");

/* check connection */
if (mysqli_connect_errno()) {
    printf("Connect failed: %s\n", mysqli_connect_error());
    exit();
}

if (!$mysqli->query("SET a=1")) {
    printf("Errormessage: %s\n", $mysqli->error);
}

/* close connection */
$mysqli->close();
?>

Welke versie van PHP draai je? Staat error_reporting aan in je php.ini?

[Tharulerz]

Het is nogal logisch dat als je

PHP:

$link->query() or die()

uitvoert dat je dan een wit scherm krijgt, dat doet die() namelijk.

Probeer eens

PHP:

$link->query() or die(mysql_error())

[FragFrog]

Uit de manual:

quote: http://nl.php.net/manual/en/mysqli.query.php

Return Values
Returns FALSE on failure. For successful SELECT, SHOW, DESCRIBE or EXPLAIN queries mysqli_query() will return a result object. For other successful queries mysqli_query() will return TRUE.

Ergo, returnwaarde is (boolean) false bij een error. Als je dan een wit scherm krijgt staat hoogstwaarschijnlijk je error_reporting setting te hoog

_{Of je hebt een lege 'die' erin natuurlijk}

[Voor 7% gewijzigd door FragFrog op 15-06-2011 00:53]

[NMe]

Nooit mysql_query() or die(mysql_error()) of vergelijkbare varianten zo in je code zetten! Dat ga je geheid per ongeluk een keer laten staan in productie, en dit is niet het soort info dat je aan hackers wil geven.

Netjes afvangen:

PHP:

if ($link->query()) {
  // bewerkingen uitvoeren
} else {
  throw new DatabaseException('foutmelding hier');
}

Uiteraard in de aanroepende code dan wel een try .. catch eromheen zetten die deze DatabaseException afvangt.

[Avalaxy]

NMe schreef op woensdag 15 juni 2011 @ 00:52:

Netjes afvangen:

PHP:

if ($link->query()) {
  // bewerkingen uitvoeren
} else {
  throw new DatabaseException('foutmelding hier');
}

Uiteraard in de aanroepende code dan wel een try .. catch eromheen zetten die deze DatabaseException afvangt.

Wat is in deze casus eigenlijk het nut er nog van een exception te gooien als je ook direct met de false aan de slag kunt?

[kokx]

Als je het in een fatsoenlijk OOP model gegooid hebt, is het juist erg handig om dan die Exception te gooien in het geval van een error. Deze kun je dan namelijk op een lager niveau opvangen, om daar dan bijvoorbeeld een 500 error te geven. En in het geval van een development versie kun je er dan ook nog alle informatie uit de Exception weergeven.

[MueR]

Avalaxy schreef op woensdag 15 juni 2011 @ 00:56:
[...]


Wat is in deze casus eigenlijk het nut er nog van een exception te gooien als je ook direct met de false aan de slag kunt?

False zegt "er ging iets fout". Exception gooi je gewoon de mysql error code in mee. Vervolgens kan je die afvangen in een aparte laag waar die error code wordt omgezet naar een toffe melding voor gebruiker (He, het is stuk, de database is vissen) en een melding naar je log (of scherm bij debug) Unknown column in table bla... False vertelt jou niet wat er mis ging, Exceptions (mits goed gebruikt) wel.

[Redsandro]

Avalaxy schreef op woensdag 15 juni 2011 @ 00:48:

if (!$mysqli->query("SET a=1")) {

Welke versie van PHP draai je? Staat error_reporting aan in je php.ini?

Hmm.. bij mij werkt dat zo niet. Error_reporting staat wel aan (22519) en ik gebruik php 5.3.1.

Tharulerz schreef op woensdag 15 juni 2011 @ 00:49:
Het is nogal logisch dat als je

PHP:

$link->query() or die()

uitvoert dat je dan een wit scherm krijgt, dat doet die() namelijk.

Probeer eens

PHP:

$link->query() or die(mysql_error())

Dat is inderdaad nogal logisch. Met pseudo-code bedoel ik dat het niet zo werkt als ik de oo notatie gebruik.

FragFrog schreef op woensdag 15 juni 2011 @ 00:52:
Ergo, returnwaarde is (boolean) false bij een error. Als je dan een wit scherm krijgt staat hoogstwaarschijnlijk je error_reporting setting te hoog

_{Of je hebt een lege 'die' erin natuurlijk}

Ja dan zal er inderdaad iets met mijn config niet kloppen. Maar het gekke is, de niet-oo variant die()t wel gewoon.

NMe schreef op woensdag 15 juni 2011 @ 00:52:
Nooit [font=mono]mysql_query() or die(mysql_error())[/] of vergelijkbare varianten zo in je code zetten! Dat ga je geheid per ongeluk een keer laten staan in productie, en dit is niet het soort info dat je aan hackers wil geven.

Netjes afvangen:

PHP:

if ($link->query()) {
  // bewerkingen uitvoeren
} else {
  throw new DatabaseException('foutmelding hier');
}

Uiteraard in de aanroepende code dan wel een try .. catch eromheen zetten die deze DatabaseException afvangt.

Die catch werkt bij mij dus ook niet. Foute query? De output stopt al nog voor de else, vandaar die @ die ik probeerde; werkt ook niet.
Anyway, ik gebruik de oo notatie van mysqli(mproved) ipv de procedural notatie van mysql, en er is niets mis met die([result => false]) als het om simpele ajaxerige communicatie gaat. Maar zover kom ik niet eens, welke methode ik ook hanteer, de output stopt gewoon na een foute query voordat dat ik een die/catch/exception kan doen.

Is DatabaseException bedoeld voor deze taak, of is dat een fictieve extension van Exception?

[HuHu]

Staat er ook niets in je PHP errorlog?

[Voutloos]

Er staat gegarandeerd wat in het errorlog. En dev voortaan aub met error_reporting op -1 en display_errors on. Je bent nu blind aan het gokken en F5'en tot je iets leuks op je scherm ziet...

[alex3305]

Als je niet zeker weet of de query klopt, dan zou ik ook even die gaan controleren. Je kunt bijvoorbeeld door middel van HeidiSQL even de query door je database heengooien om te controleren of deze wel valide is, en of je er geen foutmelding op terugkrijgt .

[MueR]

Redsandro schreef op woensdag 15 juni 2011 @ 04:42:
Die catch werkt bij mij dus ook niet. Foute query? De output stopt al nog voor de else, vandaar die @ die ik probeerde; werkt ook niet.
...
Is DatabaseException bedoeld voor deze taak, of is dat een fictieve extension van Exception?

NMe ging er hier even van uit dat je een eigen wrapper om mysql(i) hebt zitten. Hij is gewend aan de codebase binnen ons bedrijf, waar we dat standaard doen, juist om exceptions te kunnen gooien. Nou ja, voornamelijk om zonder al te veel problemen de database te kunnen switchen van mysql naar mssql, postgre of wat dan ook. De Exceptions zijn een bijkomend voordeel. En ja, in dit geval is DatabaseException gewoon een derivative van Exception, tenzij je hem echt goed uitbreid met debug-only foutmeldingen enzo.

[NMe]

Redsandro schreef op woensdag 15 juni 2011 @ 04:42:
[...]

Die catch werkt bij mij dus ook niet. Foute query? De output stopt al nog voor de else, vandaar die @ die ik probeerde; werkt ook niet.

Natuurlijk werkt die catch niet. In het geval van een onverwachte witte pagina krijg je 99 van de 100 keer een fatal error, en die vang je met exceptions niet af.

Anyway, ik gebruik de oo notatie van mysqli(mproved) ipv de procedural notatie van mysql, en er is niets mis met die([result => false]) als het om simpele ajaxerige communicatie gaat.

Mwah, ook dan is het netter, want dan kun je alle erroroutput onder elkaar afhandelen in je catches terwijl je je code amper vervuilt met foutafhandeling. Maar het ging me in mijn opmerking dan ook meer om de mysql_error(). Zet die nooit zo in je code neer als ik in mijn vorige post deed, want één keer vergeten weg te halen en je zet de deur al op een kier voor hackers.

Is DatabaseException bedoeld voor deze taak, of is dat een fictieve extension van Exception?

Fictief is hij niet, hij zit in al mijn projecten. Maar je zal hem wel zelf even moeten extenden van Exception als je hem wil gebruiken, ja.

MueR schreef op woensdag 15 juni 2011 @ 09:42:
[...]

NMe ging er hier even van uit dat je een eigen wrapper om mysql(i) hebt zitten. Hij is gewend aan de codebase binnen ons bedrijf, waar we dat standaard doen, juist om exceptions te kunnen gooien. Nou ja, voornamelijk om zonder al te veel problemen de database te kunnen switchen van mysql naar mssql, postgre of wat dan ook. De Exceptions zijn een bijkomend voordeel.

Die exceptions hebben niet zo heel veel te maken met die wrapper class hoor, ook in je script zelf kun je gewoon zelf exceptions gooien en afvangen. Dat onze wrapper class er een aantal uit zichzelf doet is mooi meegenomen maar geen beperking van het gebruik van exceptions.

En ja, in dit geval is DatabaseException gewoon een derivative van Exception, tenzij je hem echt goed uitbreid met debug-only foutmeldingen enzo.

Ook na uitbreiden is het nog afgeleid van Exception; moet ook wel, want anders kun je hem niet catchen.

[Voor 28% gewijzigd door NMe op 15-06-2011 09:53]

[Redsandro]

HuHu schreef op woensdag 15 juni 2011 @ 08:58:
Staat er ook niets in je PHP errorlog?

Voutloos schreef op woensdag 15 juni 2011 @ 09:01:
Er staat gegarandeerd wat in het errorlog. En dev voortaan aub met error_reporting op -1 en display_errors on. Je bent nu blind aan het gokken en F5'en tot je iets leuks op je scherm ziet...

Wut? Daar heb ik heeelemaal niet aan gedacht!
Display_errors staat on, maar wat is error_reporting -1?
Ik heb hem op error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

alex3305 schreef op woensdag 15 juni 2011 @ 09:11:
Als je niet zeker weet of de query klopt, dan zou ik ook even die gaan controleren. Je kunt bijvoorbeeld door middel van HeidiSQL even de query door je database heengooien om te controleren of deze wel valide is, en of je er geen foutmelding op terugkrijgt .

Als ik geen output krijg dan stap ik er even met een debugger doorheen en zie ik dat er een simpel foutje in de query zit. Dan fix ik hem en alles werkt. Maar het gebeurt steeds weer dat ik ze niet op kan vangen en dat is het probleem, niet hoe ik de query moet fixen. Bij step-debugging stopt de parser ook direct na ->query(), hij gaat niet door naar or die() of if ! of try catch

[Gamebuster]

Gebruik PDO en stel in dat-ie exception moet smijten bij fouten.

http://www.php.net/manual/en/pdo.error-handling.php

$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

[Voutloos]

Redsandro schreef op woensdag 15 juni 2011 @ 12:34:
[...]


[...]

Wut? Daar heb ik heeelemaal niet aan gedacht!
Display_errors staat on, maar wat is error_reporting -1?
Ik heb hem op error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED

In tegenstelling tot E_ALL is -1 écht alle levels.

Als ik geen output krijg dan stap ik er even met een debugger doorheen en zie ik dat er een simpel foutje in de query zit. Dan fix ik hem en alles werkt. Maar het gebeurt steeds weer dat ik ze niet op kan vangen en dat is het probleem, niet hoe ik de query moet fixen. Bij step-debugging stopt de parser ook direct na ->query(), hij gaat niet door naar or die() of if ! of try catch

+1 voor het gebruik van een debugger (doet praktisch niemand bij PHP lijkt het), maar in dit geval doe je dus veel te moeilijk.

[HuHu]

Gamebuster schreef op woensdag 15 juni 2011 @ 12:36:
Gebruik PDO en stel in dat-ie exception moet smijten bij fouten.

http://www.php.net/manual/en/pdo.error-handling.php

$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Bullshit argument, je hoeft helemaal niet van techniek te gaan veranderen.

[MueR]

NMe schreef op woensdag 15 juni 2011 @ 09:46:
Ook na uitbreiden is het nog afgeleid van Exception; moet ook wel, want anders kun je hem niet catchen.

Muggenzifter, je weet best wat ik bedoel. Een simpele derivative, als in gewoon een vrij directe class DatabaseException extends Exception {}. Wanneer je de class gewoon wel uitgebreid opzet met debugging opties is het minder een kopie en meer een feitelijke uitbreiding van de base class.

[NMe]

Hap.