streamalism.org

1. Oversikt

I denne opplæringen vil vi se på implikasjoner av å fange Kastbar.

2. Den Kastbar Klasse

I Java-dokumentasjonen er Kastbar klasse er definert som “superklassen for alle feil og unntak på Java-språket“.

La oss se på hierarkiet til Kastbar klasse:

De Kastbar klassen har to direkte underklasser - nemlig Feil og Unntak klasser.

Feil og underklassene er ukontrollerte unntak, mens underklassene til Unntak kan være enten avmerkede eller ukontrollerte unntak.

La oss se på hvilke situasjoner et program kan oppleve når det mislykkes.

3. Gjenopprettelige situasjoner

Det er situasjoner der utvinning generelt er mulig og kan håndteres med enten avmerkede eller ukontrollerte underklasser av Unntak klasse.

Et program vil for eksempel kanskje bruke en fil som ikke eksisterer på det angitte stedet, noe som resulterer i en avkrysset FileNotFoundException blir kastet.

Et annet eksempel er programmet som prøver å få tilgang til en systemressurs uten å ha tillatelse til det, noe som resulterer i en ukontrollert AdgangskontrollUnntak blir kastet.

I henhold til Java-dokumentasjonen, de Unntak klasse “indikerer forhold som en rimelig applikasjon kanskje vil fange“.

4. Uopprettelige situasjoner

Det er tilfeller der et program kan komme i en tilstand der gjenoppretting er umulig i tilfelle feil. Vanlige eksempler på dette er når et stack-overflow oppstår eller JVM går tom for minne.

I disse situasjonene kaster JVM StackOverflowError og OutOfMemoryError, henholdsvis. Som foreslått av navnene deres, er dette underklasser av Feil klasse.

I følge Java-dokumentasjonen, de Feil klasse “indikerer alvorlige problemer som en rimelig applikasjon ikke skal prøve å fange“.

5. Eksempel på gjenopprettelige og uopprettelige situasjoner

La oss anta at vi har en API som gjør det mulig for innringere å legge til unike ID-er til noen lagringsanlegg ved hjelp av addIDsToStorage metode:

klasse StorageAPI {public void addIDsToStorage (int capacity, Set storage) kaster CapacityException {if (capacity <1) {throw new CapacityException ("Kapasitet mindre enn 1 er ikke tillatt"); } int count = 0; while (count <capacity) {storage.add (UUID.randomUUID (). toString ()); telle ++; }} // andre metoder går hit ...}

Flere potensielle feilpunkter kan oppstå når de påkaller addIDsToStorage:

• CapacityException - En avkrysset underklasse av Unntak når du passerer en kapasitet verdi på mindre enn 1
• NullPointerException - En ukontrollert underklasse av Unntak hvis en null lagring verdien er gitt i stedet for en forekomst av Sett
• OutOfMemoryError - En ukontrollert underklasse av Feil hvis JVM går tom for minne før du avslutter samtidig som Løkke

De CapacityException og NullPointerException situasjoner er feil programmet kan komme seg fra, men OutOfMemoryError er en uopprettelig.

6. Fangst Kastbar

La oss anta at brukeren av API bare fanger Kastbar i prøvefangst når du ringer addIDsToStorage:

public void add (StorageAPI api, int capacity, Set storage) {prøv {api.addIDsToStorage (kapasitet, lagring); } catch (Throwable throwable) {// gjør noe her}}

Dette betyr at ringekoden reagerer på gjenopprettbare og uopprettelige situasjoner på samme måte.

Den generelle regelen i håndtering av unntak er at prøvefangst blokken må være så spesifikk som mulig for å fange unntak. Det er, et fangst-scenario må unngås.

Fangst Kastbar i vårt tilfelle bryter denne hovedregelen. For å reagere på utvinnbare og uopprettelige situasjoner hver for seg, må ringekoden inspisere forekomsten av Kastbar objekt inne i å fange blokkere.

Den bedre måten ville være å bruke en spesifikk tilnærming til å håndtere unntak og å unngå å prøve å håndtere uopprettelige situasjoner.

7. Konklusjon

I denne artikkelen så vi på implikasjonene av å fange Kastbar i en prøvefangst blokkere.

Som alltid er hele kildekoden til eksemplet tilgjengelig på Github.