07. januar 2013 - 13:34Der er
27 kommentarer og 1 løsning
Fejlhåndtering ved standard mysql contra PDO
Jeg har arbejdet med PDO i en periode, men fejlhåndteringen piner mig en smule.
Jeg har denne standard mysql-forespørgsel:
$sql_query = (" SELECT time_stamp, count_day FROM statistik ORDER BY time_stamp ASC; ");
$query_stat = mysql_query($sql_query) or die (error_handler(mysql_error()));
Forsøger jeg at hente data fra en tabel eller en kolonne der ikke eksisterer vil min error_handler-funktion blive aktiveret og jeg kan her logge fejlen.
Jeg har denne PDO forespørgsel:
try { $stsm = $conn->prepare("SELECT time_stamp, count_day FROM statistik ORDER BY time_stamp ASC"); }
catch(PDOException $pdo_error) { die (error_handler($pdo_error)); }
try { $stsm->execute(); }
catch(PDOException $pdo_error) { die (error_handler($pdo_error)); }
Med denne fanger jeg fejl i min forespørgsel eller i min execute. Jeg synes bare det er voldsom meget ekstra kode.
Er det måden at gøre det på, eller kan det gøres smartere?
Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
try { $stsm = $conn->prepare("SELECT time_stamp, count_day FROM statistik ORDER BY time_stamp ASC"); $stsm->execute(); } catch(PDOException $pdo_error) { die (error_handler($pdo_error)); }
- og skulle der være opstået tvivl i forbindelse med lidt inforståede kommentarer, så er der koncensus om, at Eriks forslag i #5 gør det samme som spørgers eget script - nøjagtig ligeså godt =)
#XIV: Men det er så anvendelsen af die(...) i catch-delen, der gør det. Ellers må man sige at anvendelsen af 2 try/catch giver god mening, hvis nummer 2 kan udføres, selv om nummer 1 fejler. Ellers bør man for læselighedens skyld anvende een try/catch.
Jeg kan godt bruge noget sparring på nedenstående spørgsmål: Skal jeg ændre errormode til silent i produktion, eller vil nedenstående script fange fejlene, og dermed ikke udgøre en risiko?
Er "if ($stsm->errorCode() == 0)" overflødig og burde udelades?
Er der noget der springer i øjnenen i nedenstående, eller noget jeg måske burde medtage?
De steder jeg bruger echo i forbindelse med fejl vil blive håndteret af en error-funktion.
Mit test-script kan jeg ikke få til at genere andre fejl end dem jeg selv echo'er.
Jeg kan ikke generere en fejl der får $stsm->errorcode til at vise en fejl.
Ændrer jeg f.eks. i tabelnavnet dør den i prepare. Laver jeg en fejl i $sql_param dør den i execute.
Den sidste fejlmulighed kan jeg ikke trigger, derfor jeg spørger om den er overflødig?
Mine try+catch vil blive lagt en funktion, således de ikke skal optræde overalt i mine scripts. Den del har jeg allerede fået til at virke. Tester bare i mit test-script, da det er mere overskueligt.
Med hensyn til hvad der skal goeres saa vil jeg sige:
demo kode:
echo og exit (eller die) er helt fin
rigtig kode:
du logger al information og saa smider du en ny exception som catches i dit presentation layer og giver brugeren en passende besked uden tekniske detaljer
"Mit test-script kan jeg ikke få til at genere andre fejl end dem jeg selv echo'er"
Der er flere fejl, der kan opstå, selv om du ikke lige kan frembringe dem selv. Fx at forbindelsen til databasen forsvinder mellem din connect og din query.
svar for mine bidrag i den sidste trediedel af traaden
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.