Näyte poikkeusjoukko
Kuvassa 1 on neljä erilaista poikkeusta, jotka on suunniteltu neljän tyyppiseen toimintaan, seuraavasti:
- BusinessException: Poikkeuksellinen tila on tapahtunut. Tämä ehto ennakoitiin, ja se voidaan tarkistaa kutsumenetelmällä välittömien toimien toteuttamiseksi.
- ParametriPoikkeus: Syötetyt tiedot eivät salli asianmukaista käsittelyä. Käyttäjää on pyydettävä syöttämään voimassa olevat tiedot uudelleen tai muuttamaan olosuhteita, joissa käsittely tapahtuu.
- Tekninen poikkeus: Tekninen ongelma, kuten virheellinen SQL-käsky, on tapahtunut. Pyydettyä toimintoa ei voida suorittaa. Käyttäjän tulee ottaa yhteyttä tukipalveluun tutkimusta varten tai kokeilla toista palvelua. Muut käyttäjät eivät vaikuta sovelluksen käyttöön.
- Kriittinen tekninen poikkeus: Tekninen ongelma, kuten tietokannan kaatuminen, on tapahtunut. Näissä olosuhteissa koko sovellusta ei voida käyttää. Käyttäjää tulisi rohkaista yrittämään myöhemmin uudelleen. Muut käyttäjät eivät saa käyttää sovellusta ennen kuin se on korjattu.
Nämä poikkeukset ovat vain yksi esimerkki; monet muut poikkeussarjat voitaisiin määritellä samalla tavalla. Esimerkiksi, Tekninen poikkeus ja Kriittinen tekninen poikkeus voidaan suunnitella yhdeksi poikkeusluokaksi, jonka looginen arvo on vakavuus määritteen. Tärkeää on keskittyä sellaisiin toimiin, jotka olisi toteutettava, pikemminkin kuin kysymykseen, joka nosti poikkeuksen.
Poikkeusloki
Vaikka poikkeussemantiikka keskittyy toteutettavaan toimintaan, esille nostettu asia on myös tärkeä. Kehitystiimi voisi esimerkiksi käyttää näitä tietoja koodin virheenkorjaukseen. Poikkeuksen suunnittelussa tiedot poikkeuksen syystä löytyvät sovelluksen virhelokitiedostosta. Kun käytössä on hyvä kirjauskehys, sen pitäisi riittää, että asiaa koskevat tiedot kirjataan poikkeussanomasta ja pinon jäljityksestä.
Ainoa kysymys siitä, miten poikkeus suunnitellaan siten, että nämä tiedot on helppo hakea. Yksi ratkaisu on tarjota poikkeus id attribuutti, joka edustaa kyseessä olevaa kysymystä. Lisäksi, jos asiasta on tullut oma poikkeus, tämä poikkeus voidaan sijoittaa sovelluksen poikkeukseen. Saapumisajankohtana alkuperäinen viesti ja pinon jäljitys voidaan noutaa sisäkkäisestä poikkeuksesta. id attribuutti- ja poikkeussisällöt ovat kaksi tapaa sisällyttää ongelmaan liittyviä tietoja itse poikkeukseen.
Suunnittelu poikkeusten kulkua
Kun olet suunnitellut poikkeukset itse, seuraava askel on miettiä, miten ne kulkevat sovelluksesi läpi. Tavallinen JEE-sovellusarkkitehtuuri koostuu pääasiassa neljästä paketista: esitys, liiketoiminta, integraatio ja pysyvyys. Poikkeukset heittävät tyypillisesti integraatio- ja pysyvyyspaketit. Yrityspaketissa sisäiset ajonaikaiset kerrokset tarttuvat tarkistettuihin poikkeuksiin niin pian kuin pystyvät, kun taas ulkokerrokset tarttuvat ajonaikaisiin poikkeuksiin ja toteuttavat asianmukaiset toimet luokansa mukaan. Voit myös heittää ja saada kiinni joitain tarkistettuja poikkeuksia yrityspaketin sisälle. Tässä järjestelmässä integraatio- ja pysyvyyspakettien sekä liiketoimintapaketin sisäisen kerroksen vastuulla on muuntaa ajonaikaiset poikkeukset toimiksi. Tämän tyyppinen tyypillinen JEE-sovellusarkkitehtuuri on esitetty kuvassa 2.
Esimerkiksi pysyvyyspaketista heitetyn poikkeuksen polku riippuu siitä, missä ongelma voidaan ratkaista. Jos soittomenetelmä pystyy ratkaisemaan ongelman, poikkeus jää välittömästi kiinni, tarvittavat toimet toteutetaan ja liiketoiminta jatkuu normaalisti. Jos ongelmaa ei voida ratkaista, poikkeus sisällytetään ajonaikaiseksi poikkeukseksi ja siirretään hiljaa yrityspaketin välikerrosten kautta sovelluksen ylempiin kerroksiin. Näissä kerroksissa, tyypillisesti jonkinlainen sovellusohjain, suorituksen aikainen poikkeus on kiinni, asianmukainen toimenpide suoritetaan ja esityskerros näyttää vastaavan virhesanoman käyttäjälle. Tarkastettujen poikkeusten välitön saaminen ja ajonaikaisten poikkeusten myöhäinen saaminen ovat tämäntyyppisen poikkeussuunnittelun kaksi pääskenaariota, kuten kuvassa 3 on esitetty.
