Jedna z cest jak zabranit vicenasobnemu logovani je dusledne priradit
kazde vyjimce jedinecne id a kontrolovat v log manageru, jestli toto id
jiz bylo zpracovano nebo ne.
Jestli vam toto pomuze, nevim, ale cesta to je.
Otazka je, jestli "logovat v okamziku vytvoreni a ne v okamziku
zachyceni" je spravna cesta, jak poskladat funkcni slozitou aplikaci.
Toto je ale jenom namet na diskuzi, odpoved neznam (a asi ani
jednoznacna neexistuje).
Mirek
Tomas Hubalek napsal(a):
Podle me je mozne vyjimku logovat dvakrat a to jednou jako log.warn() v
miste vzniku a jednou jako log.error nebo log.fatal v miste zachyceni.
Neprijdete o ni, a mobil vam bude pipat, az to bude opravdu vazne ;-)
Tom
Lubos Vrba napsal(a):
Ahoj *,
mam jednu otazku ohledne exception handlingu. V designu projektu mame
napsano, ze bysme meli nase Exceptions logovat v okamziku vytvoreni a
ne v okamziku odchyceni.
To nam pusobi radu problemu, pokud se chceme vyhnout double logovani
teze vyjimky.
Pri hledani proc to tak ma byt jsme narazili na dve veci:
1. tym vyvojaru je mlady a nezkuseny, tudiz je mozne, ze by vyjimku
chytil a zahodil bez toho aby ji zalogoval.
2. aplikace je volana z produktu 3. stran, pres WS a pokud se vyhodi v
nasi aplikaci vyjimka je treba aby jsme ji i zalogovali. V pripade
chyby database dedime vyjimku z Runtime exception
Podle meho nazoru lze oba pripady urcite obejit, 1. je absolutni
nonsence a 2. zde je otazka zda pouzivame spravne Runtime chyby a zda
lze tento problem resit jinak.
Chtel bych znat vas nazor.
Diky,
L.
