Jde o obri zakazku, kazda firma dela neco, nekdo design, ten preda nam, my to nakodujeme a jina firma dela testy.
Ted se snazime projit design a opravit nesmysly co tam jsou..
Ze je v nasi firme 70% lidi ze zkusenosti <2y je bohuzel smutna pravda.
Muzes rozvest:
V případě WS nebo RMI se dá vytvořit nějaká forma interceptoru, která vyjímky, které jdou za hranice vaší aplikace zaloguje.
Diky,
L.
On 6/13/06,
Petr Ferschmann <[EMAIL PROTECTED]> wrote:
Dobrý den,
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.
SoftEU s.r.o.
-----------------------------------
Sady Petatricatniku 31
301 00 Plzen
Czech Republic
-----------------------------------
Phone: +420 373 729 300
Fax: +420 373 729 301
Cell: +420 775 638 008
