RE: [Dialogus-develop] Nutnost vyvolani vyjimek

[Kouba T. <to...@ne...>]

Zdravim a preji pekny den,

1. to jste mne prekvapil. Doporuceni staticke metody jsem od Vas necekal :-)

2. V navrzenych design patternech jsem nenasel mnou navrhovanou metodu:

zavolani metody, ktera aplikaci ukonci pro pripady, kdy jde o kritickou
chybu. V pripade kdy nejde o kritickou chybu, resi se to jinak. Priznavam,
ze napriklad u metody ConfigMode.setValue() se mi kontrolovat navratovou
hodnotu nechce, protoze k chybe by melo dochazet velmi vyjimecne a metoda
bude volana velmi casto - vzdy pro zmene konfiguracni hodnoty, coz u
nekterych muze byt casto.

3. Zavola <code>throw new
RuntimeException("ERROR:(message)",exception);</code> take vlakno
addShutdownHook()? To je kriticke.
--
Kouba Tomas
mailto:to...@ne...

> >
> > je skutecne nutne vzdy vyvolavat vyjimku? Mam zvlastni tridu,
> ktera osetruje
> > chyby (DgsError) a jsou pripady, kdy mi na to staci. Krasny priklad je v
> > ConfigMode.setValue().
>
> Dve veci:
> 1) V pripade DgsError se vam podaril presny opak problemu, nez o kterem
> jsme spolu nekolikrat diskutovali. DgsError je Helper, ktery jenom
> zaridi zalogovani a skonci. Vzhleem k tomu, ze si NEDRZI ZADNY VNITRNI
> STAV, je naprosto zbytecne, aby se pracovalo s instanci. Je totiz
> opravdu jedno, jestli zavolate konstruktor nebo sttaicjkou metodu
> saveMessage().
>
> 2) Ctyri hlavni design patterny pro osetreni chybovych styavu:
>   a) vyhodi se obycejna vyjimka
>   b) vyhodi se Error ci RuntimeException
>   c) vrati se status provedene akce
>   d) nevrati se nic a pouze se zaloguje
>
>   Bod d) je nejmene casty, protoze se v kodu, ktery volal onen
>   test, nejste schopen onu chybu nijak zpracovat. Tato vec se pouziva
>   pouze tehdy, jedna-li se o BlackBox a de facto na vysledku testu
>   nezavisi, co se bude dal dit.
>
>   V klasickem proceduralnim jazyce se pouziva bod c) a i ja jsem
>   zastancem tohoto postupu, nebot vyhazovani vyjimek je i pres velke
>   optimalizace zbytecne drahe (a drahe je take vytvareni try { } catch
>   bloku). Smysl ma tehdy, kdyz zjisteni chyby neni az tak vyjimecne, ale
>   spis 50-50 se spravnym pruchodem.
>
>   Bod a) je popisovan jako hlavni design-pattern. mel by se ale pouzivat
>   tehdy, kdyz selhani testu je skutecnou vyjimkou, nikoli uplne beznym
>   jevem. Jinak je dale nutny predpoklad, ze z teto vyjimky se aplikace
>   muze zotavit (uzivatel zadal slovo a ma tam byt cislo).
>
>   Bod b) ma smysl tehdy, kdyz se predpoklada, ze se z chyby nelze
>   zotavit.
>
>   Pouzivani System.exit() je nedoporucovano, protoze je zbytecne moc
>   agresivni. Stejnou sluzbu zastane
>        throw new RuntimeException("ERROR:(message)",exception);
>   a navic lze takovou aplikaci spustit s nejakeho invokacniho
>   frameworku, pricemz
>        catch (RuntimeException re)
>   nezpusobi, ze poslete do kytek i tento framework. Jde napriklad o
>   spusteni ze servletu. System.exit() pak shodi i server.
>
>
> Zalezi tedy hodne na tom, jak moc casto bude dochatek k chybam. Ja
> osobne bych v tuto chvili preferoval intovy status kod metody
> setValue().
>
> Oto 'tapik' Buchta
>