Iznimke za djelovanje

Prethodna 1 2 3 4 Stranica 3 Sljedeća Stranica 3 od 4

Primjer iznimke postavljen

Na slici 1. vidite četiri vrste iznimaka dizajniranih za poduzimanje četiri vrste radnji, kako slijedi:

  1. BusinessException : Dogodilo se izuzetno stanje. Ovo je stanje bilo predviđeno i neposrednom se akcijom može provjeriti pozivom.
  2. ParameterException : Uneseni podaci ne omogućuju pravilnu obradu. Od korisnika se mora tražiti da ponovo unese valjane podatke ili da promijeni uvjete u kojima se obrada događa.
  3. TechnicalException : Došlo je do tehničkog problema poput nevaljanog SQL izraza. Zatražena operacija ne može se ispuniti. Korisnik bi se trebao obratiti službi za pomoć radi istrage ili isprobati drugu uslugu. Ostali korisnici ne utječu na upotrebu aplikacije.
  4. CriticalTechnicalException : Došlo je do tehničkog problema poput pada sustava baze podataka. U tim je uvjetima cijela aplikacija neupotrebljiva. Treba potaknuti korisnika da pokuša kasnije. Ostali korisnici ne bi trebali koristiti aplikaciju dok je ne poprave.

Ovaj skup iznimaka samo je jedan primjer; mnogi drugi skupovi iznimki mogli bi se definirati slično. Na primjer, TechnicalExceptioni CriticalTechnicalExceptionmogao bi biti dizajniran kao jedna klasa iznimke s logičkim severityatributom. Važno je usredotočiti se na vrstu radnje koju treba poduzeti, a ne na pitanje koje je pokrenulo iznimku.

Zapisivanje iznimki

Iako se semantika iznimki usredotočuje na akciju koju treba poduzeti, važno je i pitanje koje je pokrenuto. Na primjer, razvojni tim mogao bi upotrijebiti ove podatke za otklanjanje pogrešaka u kodu. U mom dizajnu iznimke, informacije o uzroku iznimke mogu se naći u datoteci dnevnika pogrešaka aplikacije. S uspostavljenim dobrim okvirom za evidentiranje, trebalo bi biti dovoljno zabilježiti informacije o problemu iz poruke o iznimci i traga steka.

Jedino pitanje ostaje kako dizajnirati iznimku tako da se ovi podaci mogu lako doći. Jedno rješenje je pružiti iznimku s atributom id koji predstavlja vrstu problema. Također, ako je problem stvorio vlastitu iznimku, ta se iznimka može ugnijezditi u iznimku aplikacije. U vrijeme hvatanja, izvorna poruka i trag stoga mogu se dohvatiti iz ugniježđene iznimke. Id atribut i iznimka gnijezde na dva načina uključuju problem vezan uz informacije u samoj iznimke.

Dizajniranje protoka iznimaka

Nakon što dizajnirate same iznimke, sljedeći je korak razmisliti o tome kako će prolaziti kroz vašu aplikaciju. Standardna arhitektura JEE aplikacija sastoji se uglavnom od četiri paketa: prezentacija, poslovanje, integracija i postojanost. Iznimke obično donose paketi integracije i trajnosti. U poslovnom paketu unutarnji runtime slojevi uhvate provjerene iznimke čim to mogu, dok vanjski slojevi uhvate runtime iznimke i poduzimaju odgovarajuće radnje prema svojoj klasi. Također možete baciti i uhvatiti neke provjerene iznimke unutar poslovnog paketa. U ovoj shemi, odgovornost paketa integracije i trajnosti, kao i unutarnjeg sloja poslovnog paketa, jest pretvaranje izuzetaka u izvođenju u akcije.Tipična arhitektura JEE aplikacija ove vrste prikazana je na slici 2.

Put iznimke izbačene iz paketa trajnosti (na primjer) ovisi o tome gdje se problem može riješiti. Ako metoda pozivanja može riješiti problem, iznimka se odmah uhvati, poduzmu se odgovarajuće radnje i posao teče normalno. Ako se problem ne može riješiti, iznimka se ugniježdi u runtime iznimku i prebacuje se tiho kroz srednje slojeve poslovnog paketa u gornje slojeve aplikacije. U tim se slojevima, obično od strane neke vrste aplikacijskog kontrolera, uhvati izuzetak tijekom izvođenja, poduzmu se odgovarajuće radnje i prezentacijski sloj prikazuje korisniku odgovarajuću poruku o pogrešci. Neposredno hvatanje provjerenih iznimaka i kasno hvatanje izuzetaka tijekom izvođenja dva su glavna scenarija u ovoj vrsti dizajna iznimki, kao što je prikazano na slici 3.