Vzorová sada výnimiek
Na obrázku 1 vidíte štyri druhy výnimiek určených na vykonanie štyroch druhov akcií:
- BusinessException: Nastal výnimočný stav. Tento stav bol predpokladaný a je možné ho skontrolovať volajúcou metódou okamžitého zásahu.
- Výnimka parametra: Zadané údaje neumožňujú správne spracovanie. Používateľ musí byť vyzvaný k opätovnému zadaniu platných údajov alebo k zmene podmienok, za ktorých dochádza k spracovaniu.
- Technická výnimka: Vyskytol sa technický problém, napríklad neplatný príkaz SQL. Požadovanú operáciu nie je možné splniť. Používateľ by mal kontaktovať technickú podporu alebo požiadať o ďalšiu službu. Používanie aplikácie inými používateľmi nie je ovplyvnené.
- CriticalTechnicalException: Vyskytol sa technický problém, napríklad zlyhanie databázy. Za týchto podmienok je celá aplikácia nepoužiteľná. Používateľa treba povzbudiť, aby sa pokúsil neskôr. Ostatní používatelia by aplikáciu nemali používať, kým nebude opravená.
Táto skupina výnimiek je iba jedným príkladom; mnoho ďalších skupín výnimiek by sa dalo definovať podobne. Napríklad, Technická výnimka a CriticalTechnicalException môže byť navrhnutý ako jedna trieda výnimiek s logickou hodnotou závažnosť atribút. Je dôležité zamerať sa skôr na druh opatrení, ktoré by sa mali podniknúť, ako na otázku, ktorá vyvolala výnimku.
Výnimka z protokolovania
Aj keď sa sémantika výnimiek zameriava na kroky, ktoré sa majú prijať, je dôležitá aj nastolená otázka. Vývojový tím by mohol napríklad tieto informácie použiť na odladenie kódu. V mojom dizajne výnimky informácie o príčine výnimky nájdete v súbore denníka chýb aplikácie. Ak je zavedený dobrý rámec na protokolovanie, malo by stačiť zaznamenávať informácie o probléme zo správy o výnimke a sledovania zásobníka.
Jediným problémom, ktorý zostáva v spôsobe návrhu výnimky, aby bolo možné tieto informácie ľahko načítať. Jedným z riešení je poskytnúť výnimku s id atribút predstavujúci druh danej emisie. Ak problém vyvolal svoju vlastnú výnimku, je možné ju vnoriť do výnimky aplikácie. V čase chytenia sa dá pôvodná správa a trasovanie zásobníka načítať z vnorenej výnimky. The id vnorenie atribútov a výnimiek sú dva spôsoby, ako zahrnúť informácie súvisiace s problémom do samotnej výnimky.
Návrh postupu výnimiek
Po vytvorení samotných výnimiek je ďalším krokom premýšľať o tom, ako budú prúdiť cez vašu aplikáciu. Štandardná aplikačná architektúra JEE sa skladá hlavne zo štyroch balíkov: prezentácia, obchod, integrácia a vytrvalosť. Výnimky zvyčajne vyvolávajú balíky integrácie a perzistencie. V obchodnom balíku vnútorné runtime vrstvy zachytia skontrolované výnimky čo najskôr, zatiaľ čo vonkajšie vrstvy zachytia runtime výnimky a vykonajú príslušné akcie podľa svojej triedy. Niektoré začiarknuté výnimky môžete tiež vyhodiť do obchodného balíka. V tejto schéme je zodpovednosťou balíkov integrácie a vytrvalosti, ako aj vnútornej vrstvy obchodného balíka, prevádzanie výnimiek za behu na akcie. Typická aplikačná architektúra JEE tohto druhu je znázornená na obrázku 2.
Cesta výnimky vyvolanej napríklad z balíka perzistencie závisí od toho, kde je možné problém vyriešiť. Ak metóda volajúceho dokáže problém vyriešiť, výnimka sa zachytí okamžite, urobia sa príslušné opatrenia a obchod bude plynúť normálne. Ak sa problém nepodarí vyriešiť, výnimka sa vnorí do runtime výnimky a potichu sa prenesie cez medzivrstvy obchodného balíka do horných vrstiev aplikácie. V týchto vrstvách, zvyčajne pomocou nejakého druhu aplikačného radiča, sa zachytí runtime výnimka, urobí sa príslušná akcia a prezentačná vrstva zobrazí používateľovi príslušné chybové hlásenie. Okamžité zachytenie kontrolovaných výnimiek a neskoré zachytenie výnimiek za behu sú dva hlavné scenáre v tomto druhu návrhu výnimiek, ako je znázornené na obrázku 3.
