ugrás a tartalomhoz

Hibakeresés és naplózó megvalósítás PHPban

balazsy · 2008. Jún. 26. (Cs), 13.37
Általános hibakeresés megfogalmazása, valamint egy konkrét naplózó mechanizmus implementációja PHP-ban
 ■
1

Naplózás

vbence · 2008. Jún. 26. (Cs), 14.49
Gondolkodtál azon, hogy esetleg kivételeken keresztül valósítod meg a naplózást? Mi szólt mellette/ellene?
2

Kivételek naplózása

balazsy · 2008. Jún. 26. (Cs), 23.21
Természetesen a kivételkezelés velejárója a dolognak, de annak a naplózás megvalósításához nincs sok köze, hiszen éppen az esetleges kivételeket szeretné az ember naplózni ... Tehát ez inkább már a mit naplózzunk témakör:
try{
}catch(Exception $ex)
{
$this->_logger->LogError($ex);
}
3

Valóban

vbence · 2008. Jún. 27. (P), 00.57
Nem zárja ki a dolog a kivételeket, de a kivételek azért nyújtanak plusz információt is a hibaüzin kívül (pl. call stack), ami persze kézzel is hozzácsapható az üzenet végére, de az még sem ugyanaz.

Igazából közben rájöttem, hogy egy notice-t mondjuk nem szeretnénk kivételen keresztül megvalósítani, úgyhogy az explicit hívás lehetőségét mindenképpen meg kell adni. Mindemellett szerintem érdemes gondolkodni a kivételkezeléssel való szorosabb kapcsolaton...
4

Nem csak hibákat kell/lehet naplózni

zila · 2008. Jún. 27. (P), 08.12
Azért is meg kell hagyni az explicit hívás lehetőségét, mert nem csak hibákat kell(het) naplózni. Fejlesztői és teszt rendszeren nagyon jól jön a részletes napló, ahol nem csak hiba bekövetkezésekor naplóz az ember. Sőt audit jellegű adatokat is lehet a naplózni pl. adatbázisba.
6

Hosszútávon talán nemjó ...

balazsy · 2008. Jún. 27. (P), 08.44
Igazándiból nem tudom, hogy pontosan mire gondoltál, amikor a kivételkezeléssel való szorosabb együttműködésre gondoltál... Talán arra, hogy saját kivételeket kéne írni, amibe bele lenne drótozva ez a mostani naplózó mechanizmus. Ez egy most is megoldható dolog, viszont csak erre támaszkodásnak van pár hátránya:
1) amit te is említettól, hogy nem minden hibatípusra jó, pl. LogDebug, LogNotice, viszont ez megoldható lenne akár külön is, s az Error-ok lennének naplózva a kivételeken keresztül
2) csak erre alapozni azért nem lenne jó, mivel ha a későbbiekben bevezetik a PHPba, hogy a beépített függvények,osztályok is kivételeket fognak kiváltani, s mivel addigra már a rendszereink úgy vannak megépítve, hogy a saját kivételek naplózásában bízunk, akkor kicsit fájhat a fejünk. Vagy akár egy külső osztály használatának a bevezetése is előhozhatja ezt a problémát
3) a kivételek azért lassítják a programot, igaz ez a webes alkalmazásoknál annyira nem ütközik ki

Én inkább azt a menetet ajánlom és követem, hogy saját kivételeket (is) kell használni, viszont ezeknek max a toString-je van felüliírva, és pár tulajdonsággal van kibővítve. Ezek a kivételek aztán a programban vannak elkapva, majd innen naplózásra, kezelésre esetleg "tovább dobásra" kerülnek.
7

megszakdna a program futása

Hodicska Gergely · 2008. Jún. 27. (P), 09.16
a rendszereink úgy vannak megépítve, hogy a saját kivételek naplózásában bízunk, akkor kicsit fájhat a fejünk.
Az el nem kapott kivételek loggolására ott a set_exception_handler(). Ezzel együtt szerintem sem a legjobb ötlet kivételekkel loggolni. Már csak azért sem, mert egy csomó esetben amikor loggolni, hibát jelezni szeretnék nem kell megszakítani a program futását, ami az exception velejárója.


Üdv,
Felhő
5

Exception

janoszen · 2008. Jún. 27. (P), 08.23
Én ezt úgy valósítottam meg, hogy az exceptionöknek van logleveljük és ennek megfelelően automatikusan köhögnek syslogba. Ezen felül van még egy debug nevű csoda, amivel a debug logba lehet beszélgetni. Személy szerint én nem építenék ekkora objektumstruktúrákat egy ilyen egyszerű feladat ellátására.