17 Mar 2011 7 commenti
La configurazione corretta delle direttive per la gestione degli errori, ed in particolare dell'error_reporting e del display_errors, richiede una fondamentale differenziazione a seconda che ci troviamo in fase di sviluppo o in fase di produzione.
La segnalazione degli errori di php è molto utile in fase di sviluppo per capire la natura degli errori nel codice che si scrive e portare notevoli benefici ai nostri applicativi: visualizzare gli errori durante lo sviluppo di una applicazione permette di ricevere un feedback immediato, accelerare il processo di sviluppo nonchè realizzare "solidi" applicativi.
Tuttavia se si è nella fase di produzione (sito on line e aperto al pbblico), la visualizzazione degli errori è indesiderata, traumatica per l'utente, imbarazzante e, nel peggiore dei casi, costituisce un rischio per la sicurezza. L'applicazione mostrando gli errori di produzione, paleserà informazioni vitali circa le funzioni ed i file coinvolti nonchè i bugs di cui soffre.
Quindi a seconda della fase in cui ci troviamo (sviluppo o produzione) gli errori dovranno essere gestiti in modo differenziato. Mentre nella fase di sviluppo è utile rilevare e visualizzare tutti gli errori, nella fase di produzione questi dovranno essere "nascosti" agli utenti ma, allo stesso tempo, sarà opportuno rilevarli e ripararli.
IMPOSTAZIONE DELLE DIRETTIVE PER LA GESTIONE DEGLI ERRORI
La loro configurazione può avvenire seguendo tre strade alternative ma che portano (più o meno) al medesimo risultato:
- modifica delle impostazione del php.ini o del httpd.conf (file file configurazione di apache);
- modifica tramite .htaccess nella root del sito;
- modifica "run-time" in un file php con le funzioni error_reporting() e ini_set().
Il primo dei metodi illustrati non sempre può essere adottato in quanto non tutti gli hosting forniscono i permessi necessari per eseguire i settaggi. Il terzo affinchè possa sortire gli effetti desiderati richiede la presenza di un file da dover includere in tutte le pagine.
Le principali direttive da impostare saranno le seguenti:
- error_reporting: stabilisce il livello degli errori da rilevare; la sua impostazione potrà avvenire ricorrendo a delle costanti o a dei numeri interi compresi fra 0 e 2147483647 (vedi dopo);
- display_errors: stabilisce se gli errori rilevati devono essere stampati a video può assumere valori boleani (on/off oppure 0/1);
- display_startup_errors: stabilisce se mostrare errori che si verificano nella fase di startup del php e può assumere valori boleani;
- log_errors: consente di impostare il file su cui salvare i log degli errori rilevati (in base all'impostazione di error_reporting); il parametro sarà il percorso a tale file;
- log_errors_max_len: consente di impostare la massima lunghezza in byte al file di log; di default è 1024 e impostandolo a 0 non si avranno limiti alla sua dimensione;
- ignore_repeated_errors: consente di non rilevare errori duplicati che si riscontrano nello stesso file e alla stessa linea; può assumere valori on e off, oppure 0 e 1.
- ignore_repeated_source: consente di non rilevare errori duplicati nello stesso file (anche se disposti su più linee); può assumere valori on e off, oppure 0 e1;
- docref_root: in caso di errori riferibili a specifiche funzioni, verrà fornito un link alla documentazione ufficiale; tale parametro accetta delle strighe che andranno a formattare il link (ad esempio 'http://php.net/');
- track_errors: può assumere valori on e off oppure 0 e 1 e consente di ottenere la variabile $php_errormsg che sarà una stringa contenete l'errore;
Per la lista completa dei parametri si rimanda al manuale ufficiale.
SETTING ERROR_REPORTING
Riporto nella seguente tabella i settaggi più comuni che è possibile effettuare all'error_reporting:
Value |
PARSE ERROR o FATAL ERROR |
WARNING |
NOTICE |
DEPRECATED |
STRICT |
E_ALL | E_STRICT |
Si |
Si |
Si |
Si |
Si |
E_ALL |
Si |
Si |
Si |
Si |
No |
E_ALL & ~E_DEPRECATED |
Si |
Si |
Si |
No |
No |
E_ALL & ~E_NOTICE & ~E_DEPRECATED |
Si |
Si |
No |
No |
No |
E_ERROR | E_PARSE |
Si |
No |
No |
No |
No |
0 |
No |
No |
No |
No |
No |
Ognuna delle costanti ha il suo rispettivo valore di tipo intero da sommare o sottrarre a seconda dell'impostazione desiderta: nell'ambito dei file php o nel php.ini si può ricorrere indifferentemente all'impostazione con costanti (preferibile) o quella di tipo numerico; nei file .htaccess (o nel httpd.cof) occorre necessarimente l'impostazione di tipo numerico.
Ricordo, inoltre, che il valore numerico di E_ALL è cambiato nelle diverse versioni di php: 30719 nelle versioni successive alla 5.3, 6143 in quelle successive alla 5.2, 2047 nelle precedenti.
Riporto di seguito il file impiegato per fare i test:
error_reporting(E_ALL | E_STRICT); // all = 2147483647 //error_reporting(E_ALL); // NO strict = 30719 //error_reporting(E_ALL & ~E_DEPRECATED); // NO deprecated, NO strict = 22527 //error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED); // NO notice, NO deprecated, NO strict = 22519 //error_reporting(E_ERROR | E_PARSE); // only parse error and fatal error = 5 //error_reporting(0); ini_set('display_error', 1); ini_set('ignore_repeated_errors', 0); ini_set('ignore_repeated_source', 0); function change (&$num) {$num += 10;} $num = 1; change(++$num); // strict ereg('z', 'xyz'); // deprecated $var .=''; // notice file('not_extists.txt'); // warning not_exists_function(); // fatal error
Piccola nota a margine: se state utilizzando una versione di php precedente alla 5 (è ora di cambiarla!) la costante E_STRICT non è definita. Inoltre, E_DEPRECATED non è definita nelle versioni di php precedenti alla 5.3 ma gli errori di questo tipo rientravano nei notice. Per ovviare a tali problemi dovrete indicare l'error_reporting con questa sintassi:
error_reporting(E_ALL | (defined('E_STRICT')? E_STRICT : 0));
Per ulteriori dettagli si rimanda, come sempre, al manuale ufficiale.
IMPOSTAZIONE DEGLI ERRORI NELLA FASE DI SVILUPPO
Se ci troviamo nella fase di svilppo è utile visualizzare ed avere traccia di tutti gli errori così che il codice scritto sia corretto sotto tutti i punti di vista. Vediamo, pertanto come è consigliabile settare le direttive in fase di sviluppo:
settaggio tramite php.ini:
error_reporting = E_ALL | E_STRICT display_errors = On display_startup_errors = On log_errors = On log_errors_max_len = 0 ignore_repeated_errors = Off ignore_repeated_source = Off track_errors = On error_log = "/percorso/file/php_error.log"
Settaggio tramite .htaccess da posizionare nella root del sito:
php_value error_reporting 2147483647 php_flag display_errors true php_flag display_startup_errors true php_flag log_errors true php_value log_errors_max_len 0 php_flag ignore_repeated_errors false php_flag ignore_repeated_source false php_flag report_memleaks true php_flag track_errors true php_value error_log /percorso/file/php_error.log
Settaggio "run-time" all'interno di un file php:
<?php error_reporting(E_ALL | E_STRICT); ini_set('display_errors',1); ini_set('display_startup_errors',1); ini_set('log_errors',1); ini_set('log_errors_max_len',0); ini_set('ignore_repeated_errors',0); ini_set('ignore_repeated_source',0); ini_set('report_memleaks',1); ini_set('track_errors',1); ini_set('error_log','/percorso/file/php_error.log'); ?>
Olimpio Romanella
Sono un appassionato di Web Developing con un particolare debole per php. Mi dedico principalmente dello sviluppo back-end ed in particolare programmazione lato server con php, sviluppo di database relazionali MySql e progettazione di CMS di piccole e medie dimensioni.
Mi avvalgo del framework javascript Jquery, utilizzando molti dei suoi plugin e nei dei miei progetti utilizzo spesso il framework MVC Codeigniter.
shop
19 January 2020 ore 16:05