Programování

Výjimky pro akci

Předchozí 1 2 3 4 Strana 3 Další Strana 3 ze 4

Ukázková sada výjimek

Na obrázku 1 vidíte čtyři druhy výjimek navržených k provádění čtyř druhů akcí, a to následovně:

  1. BusinessException: Došlo k výjimečnému stavu. Tuto podmínku bylo možné předvídat a lze ji zkontrolovat volající metodou pro okamžitou akci.
  2. ParameterException: Zadané údaje neumožňují řádné zpracování. Uživatel musí být vyzván k opětovnému zadání platných údajů nebo ke změně podmínek, za kterých dochází ke zpracování.
  3. Technická výjimka: Došlo k technickému problému, jako je neplatný příkaz SQL. Požadovanou operaci nelze splnit. Uživatel by měl kontaktovat technickou podporu nebo prozkoumat jinou službu. Použití aplikace jinými uživateli není ovlivněno.
  4. CriticalTechnicalException: Došlo k technickému problému, jako je selhání databáze. Za těchto podmínek je celá aplikace nepoužitelná. Uživatel by měl být vyzván, aby to zkusil později. Ostatní uživatelé by aplikaci neměli používat, dokud nebyla opravena.

Tato sada výjimek je pouze jedním příkladem; mnoho dalších sad výjimek lze definovat podobně. Například, Technická výjimka a CriticalTechnicalException lze navrhnout jako jedinou třídu výjimek s logickou hodnotou vážnost atribut. Je důležité zaměřit se spíše na druh opatření, které je třeba podniknout, než na problém, který výjimku vyvolal.

Protokolování výjimek

Ačkoli se sémantika výjimek zaměřuje na akci, která má být provedena, je také důležitý problém, který byl vznesen. Vývojový tým by například mohl tyto informace použít k ladění kódu. V mém návrhu výjimky lze informace o příčině výjimky najít v souboru protokolu chyb aplikace. S dobrým rámcem protokolování na místě by mělo stačit protokolovat informace o problému ze zprávy o výjimce a trasování zásobníku.

Jediným problémem, který zůstává v tom, jak navrhnout výjimku, aby bylo možné tyto informace snadno načíst. Jedním z řešení je poskytnout výjimku s id atribut představující druh dané emise. Také pokud problém vyvolal svou vlastní výjimku, lze tuto výjimku vnořit do výjimky aplikace. V době chytání lze původní zprávu a trasování zásobníku načíst z vnořené výjimky. The id vnoření atributů a výjimek jsou dva způsoby, jak zahrnout informace související s problémem do samotné výjimky.

Návrh toku výjimek

Jakmile si sami navrhnete výjimky, dalším krokem je přemýšlet o tom, jak budou procházet vaší aplikací. Standardní aplikační architektura JEE se skládá hlavně ze čtyř balíčků: prezentace, podnikání, integrace a vytrvalost. Výjimky jsou obvykle vyvolány balíčky integrace a trvalosti. V obchodním balíčku zachytí vnitřní běhové vrstvy kontrolované výjimky co nejdříve, zatímco vnější vrstvy zachytí běhové výjimky a provedou příslušné akce podle své třídy. Můžete také hodit a chytit některé kontrolované výjimky uvnitř obchodního balíčku. V tomto schématu je odpovědností balíčků integrace a vytrvalosti, jakož i vnitřní vrstvy obchodního balíčku, převést běhové výjimky na akce. Typická aplikační architektura JEE tohoto druhu je uvedena na obrázku 2.

Cesta výjimky vyvolané z balíčku persistence (například) závisí na tom, kde lze problém vyřešit. Pokud volající metoda může problém vyřešit, výjimka se zachytí okamžitě, provede se příslušná akce a obchodní tok pokračuje normálně. Pokud problém nelze vyřešit, je výjimka vnořena do běhové výjimky a předána bezobslužně prostřednictvím mezivrstev obchodního balíčku do horních vrstev aplikace. V těchto vrstvách, obvykle nějakým druhem aplikačního řadiče, se zachytí runtime výjimka, provede se příslušná akce a prezentační vrstva zobrazí uživateli příslušnou chybovou zprávu. Okamžité zachycení kontrolovaných výjimek a pozdní zachycení výjimek za běhu jsou dva hlavní scénáře v tomto druhu návrhu výjimek, jak je znázorněno na obrázku 3.

$config[zx-auto] not found$config[zx-overlay] not found