Foutmelding naar scherm of logfile

Door Ivo Breeden op 04-02-2013 21:41

1.633 views

Beste PHPers,

Wat is de beste manier om met foutmeldingen om te gaan? De constructie "... or die("melding")" is een beetje knullig, daar zijn we het wel over eens. De bezoeker krijgt dan een pagina die ineens halverwege is afgebroken met een melding.

Maar wat doe je met de echte (PDO, mysql) meldingen? Je kunt ze naar het scherm sturen want dat is erg handig voor het debuggen. Maar bij een productie versie wil je dat niet, want die meldingen vertellen een hacker erg veel over de gebruikte webserver, de database, de tabellen ...
Dus eigenlijk wil je bij de productie versie dat er op het scherm alleen een neutrale melding komt ("programmafout, waarschuw webmaster") en naar de logfile alle details (welke regel in welk script, welke query enz.).

In de PHP.ini zijn daarvoor "display_errors" en "log_errors". Die horen op een testserver te staan op On en Off, en op een productie server op Off en On. (Je kunt ze ook met [php]ini_set()[/php] instellen.) Dat werkt prima voor de standaard foutmeldingen, maar wat als je die foutmeldingen zelf ter hand neemt, bijvoorbeeld met PDO en try - catch blocks om zelf exceptions af te handelen? Als je de details van de melding met [php]echo[/php] doet, komen ze zeker op het scherm.

Eigenlijk moet je dus een errorlog() functie hebben die afhankelijk van de instellingen "display_errors" en "log_errors" de melding naar het scherm en/of de server logfile stuurt. Er is een functie [php]error_log()[/php] maar daarbij moet je toch nog zelf aangeven waar de melding heen moet.

Wat is de standaard manier om dit aan te pakken? Moet ik hiervoor een eigen errorlog() functie maken? Of is er een betere manier?

Groet,
Ivo

Ward van der Put

05-02-2013 08:57

Zelf gebruik ik vaak een combinatie van drie oplossingen:

1. Webpagina's met gebruikersvriendelijke foutmeldingen instellen als ErrorDocument in .htaccess.

2. Op kritieke fouten een HTTP-fout werpen, zodat het ErrorDocument wordt getoond.

3. Fouten loggen en rapporteren door een eigen functie in te stellen met set_error_handler() en daarin vervolgens error_log() te gebruiken.

In .htaccess leidt dit bijvoorbeeld een apart ErrorDocument voor HTTP-fout 500 en 503:

ErrorDocument 500 http://www.example.com/500.html
ErrorDocument 503 http://www.example.com/503.html

Vervolgens worden databasefouten afgehandeld als serverfouten met:


<?php
/**
 * Een verbindingsfout afhandelen als een tijdelijke serverfout.
 */
if (mysqli_connect_error()) {
    header('HTTP/1.1 503 Service Unavailable', 503, true);
    header('Retry-After: 3600');
    exit;
}

/**
 * De karakterset voor databaseverbindingen instellen op UTF-8.
 */
if (!$this->set_charset('utf8')) {
    header('HTTP/1.1 500 Internal Server Error', 500, true);
    exit;
}
?>

Ivo Breeden

05-02-2013 14:39 gewijzigd op 05-02-2013 14:50

Ward, hartelijk dank voor je reactie. Ik had me nooit goed gerealiseerd dat je zoveel kunt doen met ErrorDocuments. Dank zij jouw verhaal en je links heb ik daar veel beter idee van gekregen. Hoe werp je een HTTP fout? Ik kon het niet vinden bij "throw" maar je bedoelt waarschijnlijk dat dit met [php]header()[/php] moet? Zoals in je voorbeeld?

Maar eigenlijk is het niet precies wat ik bedoel Eigenlijk wil ik dat de plek waar gedetailleerde foutmeldingen heengaan bepaald wordt door de parameters "display_errors" en "log_errors". Net als systeem meldingen. En liefst met zo min mogelijk extra werk.

Ward van der Put

05-02-2013 15:00

Ivo Breeden op 05/02/2013 14:39:17
Eigenlijk wil ik dat de plek waar gedetailleerde foutmeldingen heengaan bepaald wordt door de parameters "display_errors" en "log_errors". Net als systeem meldingen. En liefst met zo min mogelijk extra werk.

Dat kan bijvoorbeeld zo:


<?php
set_error_handler('custom_error_handler');

function custom_error_handler($errno, $errstr, $errfile, $errline, $errcontext)
{  
    /**
     * Hier kun je de doorgegeven parameters verder afhandelen.
     */
}
?>

In je persoonlijke error handler kun je vervolgens naar eigen inzicht allerlei beslissingsregels inbouwen.

Ivo Breeden

05-02-2013 15:22

Dank je Ward. Maar die kende ik. Die werkt voor foutmeldingen van PHP zelf. Maar die komen vanzelf al in de logfile als "log_errors" aan staat en ze komen vanzelf op het scherm als "display_errors" aanstaat.
Maar waarheen moet ik iets printen of echoen opdat het dezelfde weg gaat als de "echte" PHP foutmeldingen?

Ward van der Put

05-02-2013 15:29

Ivo Breeden op 05/02/2013 15:22:34

Dank je Ward. Maar die kende ik. Die werkt voor foutmeldingen van PHP zelf. Maar die komen vanzelf al in de logfile als "log_errors" aan staat en ze komen vanzelf op het scherm als "display_errors" aanstaat.
Maar waarheen moet ik iets printen of echoen opdat het dezelfde weg gaat als de "echte" PHP foutmeldingen?

Dan kun je bijvoorbeeld trigger_error() gebruiken voor je eigen foutafhandeling, want daarbij lopen fouten vervolgens ook via de error handler van PHP óf de functie die je met set_error_handler() hebt ingesteld.

Ivo Breeden

05-02-2013 15:41

Aha dat is-em dus! Daar zocht ik naar.
Dank je wel Ward! Ik ga testen met [php]trigger_error()[/php], zodat ik dat standaard kan implementeren.

Reageren

Inloggen om te reageren