Eksempel på undtagelsessæt
I figur 1 ser du fire slags undtagelser designet til at tage fire slags handlinger som følger:
- BusinessException: Der er opstået en usædvanlig tilstand. Denne tilstand var forudset og kan kontrolleres ved hjælp af kaldemetoden til øjeblikkelig handling.
- ParameterUndtagelse: De indtastede data tillader ikke korrekt behandling. Brugeren skal bedes om at genindføre gyldige data eller om at ændre de betingelser, hvorunder behandlingen finder sted.
- Teknisk undtagelse: Et teknisk problem som en ugyldig SQL-sætning er opstået. Den ønskede handling kan ikke udføres. Brugeren skal kontakte helpdesk for undersøgelse eller prøve en anden service. Brugen af applikationen af andre brugere påvirkes ikke.
- CriticalTechnicalException: Et teknisk problem som et databasekrasj er opstået. Under disse forhold er hele applikationen ubrugelig. Brugeren skal tilskyndes til at prøve igen senere. Andre brugere bør ikke bruge applikationen, før den er blevet repareret.
Dette sæt undtagelser er kun et eksempel; mange andre undtagelsessæt kunne defineres på samme måde. For eksempel, Teknisk undtagelse og CriticalTechnicalException kunne designes som en enkelt undtagelsesklasse med en boolsk alvorlighed attribut. Det, der er vigtigt, er at fokusere på den slags handlinger, der skal foretages, snarere end på det spørgsmål, der rejste undtagelsen.
Undtagelseslogning
Selvom undtagelsessemantikken fokuserer på den handling, der skal udføres, er det spørgsmål, der er rejst, også vigtigt. Udviklingsteamet kunne for eksempel bruge disse oplysninger til at debugge koden. I mit undtagelsesdesign kan oplysninger om årsagen til undtagelsen findes i programmets fejllogfil. Med en god logningsramme på plads, bør det være tilstrækkeligt at logge information om problemet fra undtagelsesmeddelelsen og staksporingen.
Det eneste problem, der er tilbage i, hvordan undtagelsen designes, så disse oplysninger let kan hentes. En løsning er at give undtagelsen en id attribut, der repræsenterer den aktuelle problemstilling. Hvis problemet også har sin egen undtagelse, kan denne undtagelse indlejres i applikationsundtagelsen. Ved fangsttid kan den oprindelige meddelelse og stakksporingen hentes fra den indlejrede undtagelse. Det id attribut og undtagelsesindlejring er to måder at inkludere problemrelaterede oplysninger i selve undtagelsen.
Design af strømmen af undtagelser
Når du først har designet undtagelserne, er det næste trin at tænke på, hvordan de vil strømme gennem din applikation. En standard JEE-applikationsarkitektur består hovedsageligt af fire pakker: præsentation, forretning, integration og vedholdenhed. Undtagelser kastes typisk af integrations- og persistenspakkerne. I forretningspakken fanger de indre runtime-lag kontrollerede undtagelser, så snart de kan, mens de ydre lag fanger runtime-undtagelserne og træffer passende handlinger i henhold til deres klasse. Du kan også smide og fange nogle afkrydsede undtagelser inde i forretningspakken. I denne ordning er ansvaret for integrations- og persistenspakkerne såvel som for forretningspakkens indre lag at konvertere undtagelser fra runtime til handlinger. En typisk JEE-applikationsarkitektur af denne art er vist i figur 2.
Stien til en undtagelse, der kastes fra persistenspakken (for eksempel) afhænger af, hvor problemet kan løses. Hvis opkaldsmetoden kan løse problemet, fanges undtagelsen med det samme, der træffes den passende handling, og virksomheden fortsætter normalt. Hvis problemet ikke kan løses, er undtagelsen indlejret i en runtime-undtagelse og videregives lydløst gennem forretningspakkens mellemliggende lag til de øverste lag i applikationen. I disse lag, typisk af en slags applikationscontroller, fanges runtime-undtagelsen, den passende handling udføres, og præsentationslaget viser den tilsvarende fejlmeddelelse til brugeren. Umiddelbar fangst af kontrollerede undtagelser og sen fangst af runtime-undtagelser er de to hovedscenarier i denne form for undtagelsesdesign, som vist i figur 3.
