Izņēmuma kopas paraugs
1. attēlā ir redzami četru veidu izņēmumi, kas paredzēti četru veidu darbību veikšanai:
- Biznesa izņēmums: Ir noticis ārkārtas stāvoklis. Šis nosacījums bija paredzēts, un to var pārbaudīt, izmantojot tūlītējas darbības izsaukšanas metodi.
- ParameterException: Ievadītie dati neļauj pareizi apstrādāt. Jālūdz lietotājam atkārtoti ievadīt derīgus datus vai mainīt apstākļus, kādos notiek apstrāde.
- Tehniskais izņēmums: Radās tāda tehniska problēma kā nederīgs SQL priekšraksts. Pieprasīto darbību nevar izpildīt. Lietotājam vajadzētu sazināties ar palīdzības dienestu, lai veiktu izmeklēšanu, vai izmēģināt citu pakalpojumu. Tas neietekmē lietojumprogrammas izmantošanu citiem lietotājiem.
- CriticalTechnicalException: Ir radusies tāda tehniska problēma kā datubāzes avārija. Šādos apstākļos visa lietojumprogramma nav izmantojama. Lietotājs jāmudina vēlāk mēģināt vēlreiz. Citiem lietotājiem nevajadzētu lietot lietojumprogrammu, kamēr tā nav salabota.
Šis izņēmumu kopums ir tikai viens piemērs; daudzas citas izņēmumu kopas varētu definēt līdzīgi. Piemēram, Tehniskais izņēmums un CriticalTechnicalException varētu veidot kā vienu izņēmuma klasi ar būla skaitli smagums atribūts. Svarīgi ir koncentrēties uz veicamo darbību veidu, nevis uz jautājumu, kas izraisīja izņēmumu.
Izņēmuma reģistrēšana
Lai gan izņēmuma semantika ir vērsta uz veicamo darbību, svarīgs ir arī izvirzītais jautājums. Izstrādes komanda varētu, piemēram, izmantot šo informāciju koda atkļūdošanai. Manā izņēmumu noformējumā informāciju par izņēmuma cēloni var atrast lietojumprogrammas kļūdu žurnāla failā. Ja ir izveidota laba reģistrēšanas sistēma, pietiek ar to, lai reģistrētu informāciju par problēmu no izņēmuma ziņojuma un kaudzes izsekošanas.
Vienīgais jautājums, kas paliek jautājums par izņēmuma noformēšanu, lai šo informāciju varētu viegli iegūt. Viens no risinājumiem ir nodrošināt izņēmumu ar id atribūts, kas pārstāv attiecīgā jautājuma veidu. Turklāt, ja jautājumam ir savs izņēmums, šo izņēmumu var ievietot lietojumprogrammas izņēmumā. Uztveršanas laikā sākotnējo ziņojumu un kaudzes izsekošanu var izgūt no ligzdotā izņēmuma. The id atribūtu un izņēmumu ligzdošana ir divi veidi, kā pašā izņēmumā iekļaut ar informāciju saistītu informāciju.
Izņēmumu plūsmas plānošana
Kad esat izstrādājis izņēmumus, nākamais solis ir domāt par to, kā tie plūst caur jūsu lietojumprogrammu. Standarta JEE lietojumprogrammu arhitektūru galvenokārt veido četras paketes: prezentācija, bizness, integrācija un neatlaidība. Izņēmumus parasti rada integrācijas un noturības paketes. Biznesa paketē iekšējie izpildlaika slāņi pēc iespējas ātrāk uztver pārbaudītos izņēmumus, savukārt ārējie slāņi uztver izpildlaika izņēmumus un veic atbilstošas darbības atbilstoši savai klasei. Jūs varat arī iemest un noķert dažus pārbaudītus izņēmumus biznesa paketē. Šajā shēmā integrācijas un noturības pakotņu, kā arī biznesa paketes iekšējā slāņa pienākums ir izpildlaika izņēmumu pārveidošana darbībās. Šāda veida tipiska JEE lietojumprogrammu arhitektūra parādīta 2. attēlā.
No neatlaidības paketes izmestā izņēmuma ceļš (piemēram) ir atkarīgs no tā, kur problēmu var atrisināt. Ja izsaukšanas metode var atrisināt problēmu, izņēmums tiek nekavējoties noķerts, tiek veiktas atbilstošas darbības un bizness turpina darboties normāli. Ja problēmu nevar atrisināt, izņēmums tiek ievietots izpildlaika izņēmumā un klusām pa biznesa paketes starpslāņiem tiek pārsūtīts uz programmas augšējiem slāņiem. Šajos slāņos, parasti ar kāda veida lietojumprogrammu kontrolieri, tiek uztverts izpildlaika izņēmums, tiek veikta atbilstoša darbība, un prezentācijas slānis parāda atbilstošo kļūdas ziņojumu lietotājam. Tūlītēja pārbaudītu izņēmumu uztveršana un izpildes laika izņēmumu novēlota uztveršana ir divi galvenie šāda veida izņēmumu dizaina scenāriji, kā parādīts 3. attēlā.
