Pagina 1 di 4 1 2 3 ... ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 38
  1. #1

    [PILLOLA] error reporting

    cos'è?
    Error reporting significa "resoconto degli errori" ed è in soldoni il modo in cui PHP ci avvisa di qualche errore.
    In questa pillolina vedremo che ci sono diversi tipi di errore di diversa natura ed importanza, e come possiamo filtrarli e personalizzare il livello di error reporting per avere notizia solo degli errori importanti o, se siamo precisini come sarebbe bene essere, anche dei più piccoli errori.
    Va detto che per motivi di sicurezza, anche se reputo molto rara la cosa, su certi server pubblici l'error reporting potrebbe essere disabilitato.


    tipi di errore
    Possiamo avere, a grandi linee, tre tipi di errore: gli errori fatali, i warning, e i notice.
    L'importanza di questi è in ordine decrescente:

    1) Gli errori fatali sono errori gravi, tanto gravi che impediscono al parser di continuare ad interpretare lo script. Un esempio banale e molto comune può essere la mancanza del punto e virgola come terminatore di istruzione. Si tratta quindi di errori importanti che vanno assolutamente correti (d'altronde lo script non funzionerebbe altrimenti :gren: ) e che in genere sono facili da risolvere e prevenire.

    2) I warning sono degli "avvisi". Si tratta di errori che non compromettono l'esecuzione dello script, ma possono comprometterne il funzionamento logico. Un esempio di warning molto comune è quello di usare un header (ad esempio per settare un cookie) dopo aver già inviato dell'output al client. L'errore non blocca l'interpretazione dello script, ma segnala un'anomalia che spesso è importante a livello logico (ad esempio: il cookie non è stato settato).

    3) I notice sono spesso trascurati dai programmatori, ma sarebbe buona abitudine ricordarsi anche di queste misere "notiziole" che ci avvisano di piccole imperfezioni nel nostro codice. Un classico esempio di notice è l'uso di una variabile non settata (badate bene che non settata non vuol dire nè che sia una stringa vuota, nè lo 0, nè false, nè il valore NULL.. che però viene assegnato dal parser in mancanza di un valore migliore). Per evitare questo tipo di errori basta controllare che una variabile sia settata prima di usarla.. e in caso contrario una gestione possibile è quella di usare un valore di default che non comprometta la logica dello script.
    Per esempio prima di usare una variabile come condizione di qualsiasi costrutto, sarebbe opportuno un controllo del genere:
    Codice PHP:
    if(!isset($var)) $var '';
    //se la variabile non ha un valore, le do un valore di inizializzazione 
    I notice, come avrete capito, non bloccano l'interpretazione dello script, e nella stragrande maggioranza dei casi le imperfezioni segnalate non creano errori che compromettano il funzionamento logico del nostro script.
    Tuttavia per non sottovalutare troppo il problema è il caso di fare un esempio di errore molto fagiano che produrrebbe risultati inaspettati e apparentemente inspiegabili in uno script:

    Codice PHP:
    $prova1 1;
    $prova2 1;
    if (
    $prova1 == $porva2) echo "uguali";
    else echo 
    "diversi"
    scrivendo velocemente e leggendo ancora più velocemente potreste non accorgervi che nella condizione dell'if il nome della seconda variabile presenta un refuso... senza un notice vi verrebbe stampato "diversi".. perchè a rigor di logica 1 è diverso da NULL (i contenuti delle due variabili rispettivamente), anche se ovviamente non era questo il vostro intento. Il notice invece vi avvisa che state usando una variabile non settata e quindi vi insospettisce prima ancora che si possa verificare la condizione d'errore
    E' quindi buona norma, anche stilistica, usare un error reporting rigido, almeno in fase di sviluppo.


    Costanti d'errore
    Il PHP riconosce vari tipi di errore appartenenti alle categorie suddette mediante delle maschere numeriche, o delle costanti predefinite che possono sostituire i meno mnemonici valori numerici. Tra l'altro si consiglia di usare le costanti per garantire la compatibilità con versioni presenti passate e future di php, e quindi vedremo solo queste:

    E_ERROR, E_WARNING, E_NOTICE sono le costanti che indicano genericamente le tre classi di errore sopra spiegate e si tratta sempre di errori a run time.

    Ci sono altri tipi di errore che sono spesso dei casi particolari dei tre casi visti che generalmente il programmatore medio può tranquillamente ignorare ma che riporto per completezza:

    E_PARSE indica errori di parsing a tempo di compilazione.

    E_CORE_ERROR ed E_CORE_WARNING sono le costanti che identificano rispettivamente errori fatali e warning del core di PHP e si possono verificare quando il PHP viene inizializzato. Si tratta quindi di errori di programmazione del PHP stesso, e non di chi usa il PHP.

    E_COMPILE_ERROR ed E_COMPILE_WARNING sono le costanti che identificano rispettivamente errori fatali e warning che possono essere generati a tempo di compilazione dello Zend Scripting Engine.. non possono chiaramente essere generati da funzioni e sono errori a tempo di compilazione.

    E_USER_ERROR, E_USER_WARNING ed E_USER_NOTICE sono le costanti che identificano errori ewarning e notice generati dall'utente con l'opprtuna funzione trigger_error()

    Oltre queste costanti abbiamo la costante "jolly" che indica tutti gli errori possibili e si chiama E_ALL.

    Le costanti appena viste sono utili per definire un livello personalizzato di errore. Ciò può essere fatto globalmente per tutti gli script che girano sulla nostra macchina, oppure localmente, script per script. Vediamo come.

    settaggio globale dell'error_reporting
    Di default PHP (almeno dalla versione 4.0 alla 4.3.4) segnala tutti gli errori eccetto i notice, possiamo modificare questa impostazione per qualsiasi ragione (purchè ci rendiamo conto che si tratta di un settaggio delicato) andando a modificare il php.ini.
    Ovviamete dobbiamo essere amministratori del sistema o avere un server in housing per apportare questa modifica.. possiamo provare senza problemi in locale sulla nostra macchina.
    La direttiva "error_reporting" si trova nel vostro php.ini, basta cercarla con la funzione di ricerca del vostro editor preferito e troverete presumibilmente qualcosa del genere:

    codice:
    error_reporting  =  E_ALL & ~E_NOTICE
    la tilde (~) ha valore di negazione.. quindi la precedente sintassi indica al php di segnalare tutti gli errori eccetto i notice.
    Come già detto sopra è buona norma essere rigidi almeno in fase di sviluppo, ed impostare l'error reporting semplicemente su E_ALL. I nostri script saranno più sicuri e anche stilisticamente miglori. E' antipatico usare del codice fatto da terze persone e ritrovarsi pieni di notice

    Altre combinazioni possono essere ottenute con l'operatore | (and) e quello ^ (or).

    Come detto inizialmente per motivi di sicurezza si potrebbe voler disattivare l'error_reporting e usare magari il logging in modo da non dare in output informazioni che potrebbero essere interessanti per un attaccante. Questo si ottiene sempre editando il php.ini impostando il seguente parametro
    codice:
    display_errors = Off
    Altri settaggi utili (riportati con i loro valori di default nella versione 4.3.4) sono
    codice:
    log_errors = Off
    che abilita o disabilita appunto il logging degli errori..
    codice:
    log_errors_max_len = 1024
    che imposta una dmensione massima (in kb) al file di log degli errori. Il valore 0 indica una dimensione illimitata.

    Curiosando nel php.ini (cosa sempre molto istruttiva ) potete infine trovare altri settaggi che evito di menzionare.


    settaggio localizzato
    Se non avete accesso al php.ini potete comunque modificare il livello di error reporting mediante la funzione error_reporting() che prende come parametro una delle costanti viste prima (o una loro composizione).
    Il valore restituito dalla funzione è il settaggio precedentemente in vigore.

    Codice PHP:
    $vecchiolivello error_reporting(E_ALL);
    //oppure semplicemente error_reporting(E_ALL); se il valore di ritorno non ci serve 
    Chiaramente l'ambito di validità del settaggio è lo stesso di quello di una variabile dichiarata nello stesso punto... per cui vale solo per il file in cui si trova e per quelli che lo includono... non vale per altri file nè chiaramente per altri utenti del vostro server.

    Il vantaggio nell'uso di questa funzione è l'indipendenza dal server. Su qualsiasi server o in qualsiasi modo vengano cambiate le impostazioni del vostro server, il vostro script continuerà a mantenere il suo error reporting.

    Parimenti, possiamo personalizzare il livello d'errore utilizzando la fuzione set_ini() in modo opportuno. Ma è più semplice e chiaro utilizzare la funzione vista quindi non mi soffermo oltre.


    errori personalizzati
    Senza impelagarci nella gestione avanzata degli errori, esaminiamo un modo semplice e ben noto di avere messaggi d'errore personalizzati e introduciamo la funzione die()[alias di exit()] e l'operatore @.

    L'operatore "@", anteposto ad una funzione, ne blocca i messaggi di errore. Semplicemente se l'errore e critico lo script viene terminato, altrimenti si va oltre senza segnalazioni. Badate bene che un uso del genere non è asolutamente consigliato, ma può essere usato in combiazione con die().

    La funzione die() ha lo scopo di terminare immediatamente l'interpretazione dello script fornendo alternativamente uno exit status o un messagio d'errore a seconda che il suo parametro sia un intero o una stringa. L'exit status sarà un concetto noto a chi programma in C, che non ha però grande utilità nella programmazione web. La possibilità di fornire in output una stringa invece si rivela utile per la personalizzazione del messaggio d'errore.

    Un output di errore del genere
    Codice PHP:
    @funzione() or die('errore nella chiamata di funzione'); 
    è molto più gradevole di un fatal error
    Una così semplice gestione, oltre a spaventare di meno l'utente, maschera possibili informazioni utili ad un malintenzionato. E' possibile personalizzare la funzione usando anche gli identificatori __LINE__ e __FILE__ per avere informazioni sulla riga e il file in cui si sono verificati gli errori.

    Ci sono possibilità di manipolare l'errore in modo molto più avanzato come con trigger_error() o con le eccezioni nella OOP [le eccezioni saranno supportate a partire dalla versione 5 di php], ma non mi sembra il caso di dilungarmi oltre in questa sede


    Ovviamente tutti sono invitati a correggermi, ad approfondire qualcosa che posso aver trattato superficialmente, ad aggiungere qualsiasi cosa in tema!


    tutti meno andr3a!!!!



  2. #2
    Ottima guidoz !!

    Ora me la leggo... mi serviva proprio !! :metallica

  3. #3
    Utente bannato
    Registrato dal
    Aug 2001
    Messaggi
    696
    bella guidoz :metallica

    ora la aggiungo

  4. #4
    Originariamente inviato da bubu sette sette
    bella guidoz :metallica

    ora la aggiungo



    :gren:
    Addio Aldo, amico mio... [03/12/70 - 16/08/03]

  5. #5
    Utente bannato
    Registrato dal
    Aug 2001
    Messaggi
    696
    L'ha già aggiunta gm

  6. #6
    Originariamente inviato da bubu sette sette
    bella guidoz :metallica

    ora la aggiungo
    ma lollone!



    gm.. mi vedo già lui che corre ad editare il suo post dopo aver visto che era già tra le pillole :gren:

  7. #7
    Utente bannato
    Registrato dal
    Aug 2001
    Messaggi
    696
    Originariamente inviato da gm



    :gren:
    :sgrat:

  8. #8
    Originariamente inviato da bubu sette sette
    L'ha già aggiunta gm
    mi sa che il tuo cervello non è notice free :zamm:

  9. #9
    Utente bannato
    Registrato dal
    Aug 2001
    Messaggi
    696
    Oserei fare una piccola aggiunta alle possibilità per il settaggio locale

    Io uso molto questo metodo.
    In un file htaccess
    php_value "error_reporting" "2047"
    Poi quando ho finito lo sviluppo dello script lo tolgo.
    E' facile che lo possa usare anche chi non ha a ccesso al php.ini e secondo me è + comodo.

    La solita stringa dovrebbe funzionare anche dentro al virtualhost nel file httpd.conf ma non ho mai provato


  10. #10
    Originariamente inviato da bubu sette sette
    Oserei
    osa sempre contro le mie fagianate

    cmq una cosa del genere mi confonde un attimo le idee... settando il livello d'errore in un .httaccces vale per l'intera direcotry o che?

    quando hai un file incluso ovunque [esemio un config] non basta metterlo lì?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.