Eksempel på unntakssett
I figur 1 ser du fire typer unntak designet for å utføre fire typer handlinger, som følger:
- BusinessException: En eksepsjonell tilstand har oppstått. Denne tilstanden var forutsett og kan kontrolleres ved å ringe metoden for umiddelbar handling.
- Parameter unntak: De oppgitte dataene tillater ikke riktig behandling. Brukeren må bli bedt om å legge inn gyldige data på nytt eller om å endre vilkårene der behandlingen skjer.
- Teknisk unntak: Det har oppstått et teknisk problem som en ugyldig SQL-setning. Den forespurte operasjonen kan ikke oppfylles. Brukeren bør kontakte kundestøtten for etterforskning eller prøve en annen tjeneste. Bruken av applikasjonen av andre brukere påvirkes ikke.
- CriticalTechnicalException: Det har oppstått et teknisk problem som en databasekrasj. Under disse forholdene er hele applikasjonen ubrukelig. Brukeren bør oppfordres til å prøve på nytt senere. Andre brukere bør ikke bruke applikasjonen før den er reparert.
Dette settet med unntak er bare ett eksempel; mange andre unntakssett kan defineres på samme måte. For eksempel, Teknisk unntak og CriticalTechnicalException kan utformes som en enkelt unntaksklasse med boolsk alvorlighetsgrad Egenskap. Det som er viktig er å fokusere på hva slags handlinger som skal gjøres, snarere enn på saken som reiste unntaket.
Unntakslogging
Selv om unntakssemantikken fokuserer på handlingen som skal utføres, er også saken som er reist viktig. Utviklingsteamet kan for eksempel bruke denne informasjonen til å feilsøke koden. I mitt unntaksdesign kan informasjon om årsaken til unntaket bli funnet i programmets feilloggfil. Med et godt loggerammeverk på plass, bør det være tilstrekkelig å logge informasjon om problemet fra unntaksmeldingen og stabelspor.
Det eneste problemet som gjenstår i utformingen av unntaket slik at denne informasjonen enkelt kan hentes. En løsning er å gi unntaket en id attributt som representerer den aktuelle saken. Hvis problemet har kastet sitt eget unntak, kan dette unntaket også være nestet i applikasjons unntaket. Ved fangsttid kan den opprinnelige meldingen og stakksporingen hentes fra det nestede unntaket. De id attributt og unntak hekking er to måter å inkludere problemrelatert informasjon i selve unntaket.
Designe strømmen av unntak
Når du har designet unntakene selv, er neste trinn å tenke på hvordan de vil strømme gjennom søknaden din. En standard JEE-applikasjonsarkitektur består hovedsakelig av fire pakker: presentasjon, virksomhet, integrasjon og utholdenhet. Unntak kastes vanligvis av integrasjons- og utholdenhetspakker. I forretningspakken fanger de indre kjøretidslagene kontrollerte unntak så snart de kan, mens de ytre lagene fanger kjøretids unntakene og utfører passende tiltak i henhold til klassen. Du kan også kaste og fange noen avmerkede unntak i forretningspakken. I denne ordningen er ansvaret for integrasjons- og utholdenhetspakker, så vel som for forretningspakkens indre lag, å konvertere unntak for kjøretid til handlinger. En typisk JEE-applikasjonsarkitektur av denne typen er vist i figur 2.
Stien til et unntak som kastes fra utholdenhetspakken (for eksempel) avhenger av hvor problemet kan løses. Hvis anropsmetoden kan løse problemet, blir unntaket fanget umiddelbart, passende tiltak iverksatt, og virksomheten fortsetter normalt. Hvis problemet ikke kan løses, er unntaket nestet i et kjøretidsunntak og føres stille gjennom forretningspakkens mellomliggende lag til de øvre lagene i applikasjonen. I disse lagene, vanligvis av en slags applikasjonskontroller, blir runtime-unntaket fanget, den riktige handlingen utført, og presentasjonslaget viser den tilsvarende feilmeldingen til brukeren. Umiddelbar fangst av sjekket unntak og sen fangst av unntak for kjøretid er de to hovedscenariene i denne typen unntaksdesign, som vist i figur 3.
