0 commenti php

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.

0 Commenti presenti