pokud by takováto vyjímka byla zalogována jen dvakrát tak je to ještě v pohodě :-)
My vždy logujeme v míste vyřešení chyby (tj. ne tam kde jí obalujeme obecnější vyjímkou).
Aby jste zabránil odchycení a zahození tak doporučuji různé nástroje pro statickou analýzu kódu (např. PMD).
Pokud už ale teď nedůvěřujete vývojařům, proč je najímáte?
V případě WS nebo RMI se dá vytvořit nějaká forma interceptoru, která vyjímky, které jdou za hranice vaší aplikace zaloguje.
S pozdravem
Petr Ferschmann
Lubos Vrba píše v Út 13. 06. 2006 v 12:05 +0200:
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.
|
smime.p7s
Description: S/MIME cryptographic signature
