Depistarea scripturilor PHP
După cum știți, dacă există o eroare, PHP va da în cel mai bun caz numărul de linie în care a apărut, și scurta descriere a acestuia, și în cel mai rău caz (dacă eroarea este dezactivată în setările de găzduire) - doar o pagină goală. Acest lucru nu este foarte convenabil pentru depanare, precum și pentru utilizatorul final. Se pune întrebarea: modul de a face ca ieșirea mesajului de eroare să fie mai informativă.
Se pare că totul este destul de simplu. În PHP, există o funcție specială set_error_handler (), care vă permite să specificați propriul handler de eroare. Singurul său parametru este numele funcției handler, care se numește atunci când apare o eroare. Funcția Handler are 4 parametri: numărul de eroare, textul de eroare, numele fișierului, în care a apărut eroarea și numărul de linie din acest fișier.
Dar este posibil ca aceste date să nu fie suficiente. Este adesea necesar să afișați întreaga stivă de apeluri pentru a înțelege exact unde a apărut eroarea. Puteți obține stivă utilizând funcția debug_backtrace, care returnează o serie de callback-uri. Fiecare element al acestei matrice este un hash cu următoarele câmpuri: numele funcției - funcția, argumentele funcțiilor args, fișierul - numele fișierului în care a fost apelat. line este numărul liniei unde a fost apelată funcția.
Atenție: în unele cazuri, fișierul și linia nu sunt specificate, verificați-le întotdeauna (și într-adevăr indicele matricei) cu isset și constantele cu definit, altfel va apărea un apel recursiv al instrumentului de eroare. În plus, dacă efectuați ieșirile argumentelor la funcții, trebuie să luați măsuri astfel încât parola din baza de date să nu fie dată în cazul în care apare eroarea în timpul conectării la DBMS (adică atunci când apelați funcția mysql_connect sau altele asemenea). Cea mai simplă opțiune este înlocuirea cu str_replace cu asteriscuri sau alte caractere speciale înainte de ieșire.
Luați în considerare un exemplu de funcție de manipulare:
De asemenea, de multe ori, atunci când depanarea scripturilor, trebuie să ieșiți valoarea oricărei variabile pentru a înțelege la ce etapă se fac datele incorecte. Utilizarea lui print_r nu este cea mai bună soluție (mai ales atunci când se depanează pe un site live), deoarece valoarea poate fi redată într-un loc necorespunzător (de exemplu, dacă se utilizează un șablon chiar înainte de antetul HTML). În plus, soluția mai corectă este aceea de a stoca valoarea într-o variabilă de depanare, pe care o puteți emite ulterior, unde aspectul ei nu va interfera (de exemplu, în subsolul site-ului).
Folosesc această funcție în acest scop:
Această funcție scapă toți parametrii care îi sunt transmiși și o stochează în variabila globală $ GLOBALS ['IntBF_debug'], din care poate fi transmisă în orice loc potrivit cu ecoul obișnuit.
Dacă doriți să avorteze scriptul cu o eroare la inițiativa dezvoltator (de exemplu, după o interogare SQL incorectă), utilizați funcția trigger_error. Această funcție are doi parametri: prima - un șir de caractere, cu un mesaj de eroare care va fi transmis la errstr handler parametrul $, iar al doilea - un cod de eroare, care poate fi una dintre cele trei constante: E_USER_ERROR (va conduce la finalizarea implementării), E_USER_WARNING, E_USER_NOTICE .
Folosirea acestor funcții poate contribui la economisirea îndelungată a timpului și la îmbunătățirea accesibilității site-ului. Dar, în același timp, nu ar trebui să uităm că există situații în care acest handler nu funcționează, de exemplu, atunci când o funcție inexistentă este apelată sau conectată utilizând un script care conține o eroare de sintaxă.
Nu există încă recenzii.
Articole similare
Trimiteți-le prietenilor: