Programiranje

Izjeme pri ukrepanju

Prejšnja 1 2 3 4 Stran 3 Naprej Stran 3 od 4

Vzorčni nabor izjem

Na sliki 1 vidite štiri vrste izjem, zasnovanih za izvajanje štirih vrst ukrepov, in sicer:

  1. BusinessException: Prišlo je do izjemnega stanja. Ta pogoj je bil predviden in ga je mogoče takoj poklicati s klicno metodo.
  2. ParameterException: Vneseni podatki ne omogočajo ustrezne obdelave. Uporabnika je treba pozvati, da znova vnese veljavne podatke ali da spremeni pogoje, v katerih poteka obdelava.
  3. TechnicalException: Prišlo je do tehnične težave, kot je neveljaven stavek SQL. Zahtevane operacije ni mogoče izpolniti. Uporabnik naj se za preiskavo obrne na službo za pomoč ali preizkusi drugo storitev. Na uporabo aplikacije s strani drugih uporabnikov to ne vpliva.
  4. CriticalTechnicalException: Prišlo je do tehnične težave, kot je zrušitev baze podatkov. V teh pogojih je celotna aplikacija neuporabna. Uporabnika je treba pozvati, naj poskusi pozneje. Drugi uporabniki ne smejo uporabljati aplikacije, dokler je ne popravijo.

Ta niz izjem je le en primer; številne druge izjeme lahko definiramo podobno. Na primer, TechnicalException in CriticalTechnicalException lahko zasnovan kot en izjemen razred z logično vrednostjo resnost atribut. Pomembno je, da se osredotočimo na vrsto ukrepov, ki jih je treba sprejeti, namesto na vprašanje, ki je sprožilo izjemo.

Beleženje izjem

Čeprav se semantika izjem nanaša na ukrepe, ki jih je treba izvesti, je pomembno tudi vprašanje, ki je bilo izpostavljeno. Razvojna skupina bi na primer lahko te podatke uporabila za razhroščevanje kode. V moji zasnovi izjeme lahko informacije o vzroku izjeme najdete v datoteki dnevnika napak aplikacije. Z vzpostavljenim dobrim okvirom za beleženje bi moralo zadostovati zapisovanje informacij o težavi iz sporočila o izjemi in sledi sklada.

Edino vprašanje ostaja pri oblikovanju izjeme, tako da je te informacije mogoče zlahka pridobiti. Ena od rešitev je zagotoviti izjemo z id atribut, ki predstavlja vrsto zadeve. Če je težava povzročila lastno izjemo, jo lahko ugnezdi v izjemo aplikacije. Ob ulovu lahko iz ugnezdene izjeme pridobite izvirno sporočilo in sled sklada. The id gnezdenje atributov in izjem je dva načina za vključitev informacij o težavah v samo izjemo.

Oblikovanje toka izjem

Ko oblikujete same izjeme, je naslednji korak razmisliti o tem, kako se bodo pretakale skozi vašo aplikacijo. Standardna arhitektura aplikacij JEE je v glavnem sestavljena iz štirih paketov: predstavitve, poslovanja, integracije in trajnosti. Izjeme običajno povzročajo paketi integracije in trajnosti. V poslovnem paketu notranje izvajalne plasti ujamejo preverjene izjeme takoj, ko lahko, medtem ko zunanje plasti ujamejo izjeme med izvajanjem in izvedejo ustrezne ukrepe glede na svoj razred. V poslovnem paketu lahko vržete in ujamete tudi nekatere preverjene izjeme. V tej shemi je odgovornost paketov integracije in trajnosti ter notranjega sloja poslovnega paketa pretvorba izjem izvajalnega okolja v dejanja. Tipična arhitektura aplikacije JEE te vrste je prikazana na sliki 2.

Pot izjeme, vržene iz paketa trajnosti (na primer), je odvisna od tega, kje je težavo mogoče rešiti. Če lahko klicna metoda reši težavo, se izjema takoj ujame, sprejme ustrezen ukrep in podjetje teče normalno. Če težave ni mogoče rešiti, je izjema ugnezdena med izvajalno izjemo in se tiho posreduje skozi vmesne sloje poslovnega paketa v zgornje sloje aplikacije. V teh plasteh, običajno s pomočjo nekega krmilnika aplikacij, se ujame izjema med izvajanjem, izvede ustrezno dejanje in predstavitveni sloj prikaže uporabniku ustrezno sporočilo o napaki. Takojšnji ulov preverjenih izjem in pozen ulov izjem med izvajanjem sta glavna scenarija tovrstne zasnove izjem, kot je prikazano na sliki 3.

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