PHP e il report degli errori
Giovedì 18 Marzo 2010 - 08:01
di Andrea Ganduglia
PHP offre alcuni importanti strumenti per la visualizzazione e il logging degli errori che permettono allo sviluppatore di determinare quali errori devono essere mostrati e in quale situazione. Il più importante è certamente error_reporting() attraverso il quale è possibile decidere con quale granularità tener conto degli errori.
Per esempio:
error_reporting(E_ALL); // Mostra tutti gli errori error_reporting(E_ALL ^ E_NOTICE); // Esclude i NOTICE error_reporting(0); // Non mostra nulla error_reporting(1); // Solo gli errori fatali (E_ERROR)
I parametri di questa funzione possono essere espressi attraverso delle costanti predefinite o relativi valori binari.
Inoltre, è possibile decidere se mostrare gli errori a video o se ridirigerli in un file. Per farlo si può agire attraverso delle direttive ini_set() che possono essere espresse direttamente nello script, in un file .htaccess, nella configurazione del virtual host o direttamente nel php.ini; in caso la direttiva sia espressa in più di un modo la priorità seguirà l’ordine espresso (script, .htaccess, apache, php.ini), permettendoci di sovrascrivere localmente i valori.
display_errors (On/Off) indica se visualizzare o meno gli errori a video.
log_errors (On/Off) indica se attivare il logging su file degli errori.
error_log (string) indica il nome del file dove loggare gli errori. Il file deve essere scrivibile dal web server.
Una configurazione che uso spesso è la seguente:
error_reporting(E_ALL ^ E_NOTICE);
ini_set("log_errors", "On");
ini_set("error_log", "/path/file/di/log");
if(stristr($_SERVER['REQUEST_URI'],'?show_errors')){
ini_set("display_errors","On");
}else{
ini_set("display_errors","Off");
}
In questo modo tengo traccia di tutti gli errori tranne dei notice e li mostro a video esclusivamente per debug se aggiungo alla URL dello script ?show_errors, evitando che l’utente visualizzi stringhe di errore.
Categoria: PHP e Open Source | Permalink
Commenti
1
Grazie per queste utili indicazioni metodologiche
# - postato da Xavier - 18 Marzo 2010 - 12:29
2
Solo un appunto: ini_set() potrebbe non essere sempre disponibile perchè disabilitata da sistemisti molto prudenti (è infatti una delle misure base per prevenire problemi con smanettoni) o semplici hoster molto restrittivi
3
Salve, sono un hoster molto restrittivo :-)
Il problema è che il debug non andrebbe mai effettuato sul server di produzione, ma mi ritrovo con clienti che mi chiedono sempre come mai non si vedono gli errori che…
Sono arcistufo di spiegare che il debug dovete farvelo a casa vostra, sul server al limite potete solo aggiustare ciò che alle volte per un problema derivato dalla diversa configurazione non funziona.
In realtà proprio perché alla fine devi venire a compromessi, così fin dal 2003 sui miei server ho attivata in modo predefinito la modalità che permette di avere il debug in un file chiamato error_log ma tanto che lo dico a fare?
Scusate questo mio sfogo, sembra una pubblicità ma è una vita che lo vado dicendo, anzi dal 2003, ma la gente non riesce a compredere che mettere in chiaro una stringa che contenga non solo il percorso assoluto dei file ma anche il nome dell’account e infine ancora più pericoloso l’errore che si è venuto a creare è la cosa più bella che un cracker può chiedervi :-)M.
# - postato da Marco Grazia - 19 Marzo 2010 - 15:03
4
Direi che ogni utente avrebbe il diritto di sapere perché la sua applicazione non funziona. E se gli nascondiamo gli errori non lo saprà mai!
# - postato da Andrea - 19 Marzo 2010 - 15:08
5
Ah, l’esterna lotta tra sistemisti e sviluppatori.. ;)
Alla fine secondo me hanno ragione entrambi:
è vero che noi programmatori non pensiamo che certe restrizioni nascono per delle esigenze, ma è anche vero che lavorare direttamente su un server identico al server di produzione ci permetta di risparmiare tanto tempo, oltre al fatto che a volte il cliente ha necessità così urgenti da dover lavorare direttamente in produzione…Io ho risolto con due domini di terzo livello, uno di produzione (www.) e uno di sviluppo (quelcheveolete.), quest’ultimo possibilmente accessibile solo dagli IP degli sviluppatori.
L’error_log è decismante scomodo, al massimo va bene esclusivamente per tracciare gli errori sul server di produzione..
6
L’eterna lotta è dentro di me, essendo uno sviluppatore suo malgrado divenuto sistemista :-)
@andrea, non ha compreso un gran che del problema, nessuno ti impedisce di vedere gli errori, ma anzi ti si permette di vederli solo te, questo per una sicurezza del server ma anche tua.
Se io per un errore leggo che so: /home/andrea/public_html/config_autor.php alla riga 5 del file nella funzione vattelapescare() si è verificato un errore…. ho dato una bella mano a chi è interessato a sapere che il tuo account su quel server è andrea, che alla riga 5 del file config_autor.php c’è un errore che posso sfruttare, insoma perché rendere pubbliche queste cose?
C’è il modo per evitarlo, ovvero inserire tutto dentro un file che puoi leggere solo tu; come vedi nessuno ti nasconde nulla, non a te almeno ;-)
Spero di aver risposto anche a sante, è inutile che crei domini di terzo livello, la macchina è sempre la stessa, mi basta andare sul dominio di testing e sono a cavallo :-)
L’error_log serve proprio a tracciare gli errori del server di produzione è di questo che si sta parlando.
Un server di sviluppo non dovrebbe nemmeno essere in rete o al limite va segato completamente periodicamente perché non sai a priori cosa c’è dentro ;-)M.
# - postato da Marco Grazia - 26 Marzo 2010 - 00:21