streamalism.org

1. Introduksjon

I denne opplæringen tar vi en titt på kaste og kaster i Java. Vi forklarer når vi skal bruke hver av dem.

Deretter viser vi noen eksempler på deres grunnleggende bruk.

2. Kaste og Kaster

La oss starte med en rask introduksjon. Disse nøkkelordene er relatert til unntakshåndtering. Unntak heves når den normale strømmen av søknaden vår forstyrres.

Det kan være mange grunner. En bruker kan sende feil inndata. Vi kan miste en forbindelse, eller det kan oppstå en annen uventet situasjon. Håndtering av gode unntak er en nøkkel for å holde applikasjonen vår i bruk etter at de ubehagelige øyeblikkene ser ut.

Vi bruker kaste nøkkelord for eksplisitt å kaste et unntak fra koden. Det kan være hvilken som helst metode eller statisk blokk. Dette unntaket må være en underklasse av Kastbar. Det kan også være en Kastbar seg selv. Vi kan ikke kaste flere unntak med en enkelt kaste.

Kaster nøkkelord kan plasseres i metodedeklarasjonen. Det angir hvilke unntak som kan kastes fra denne metoden. Vi må håndtere disse unntakene med prøvefangst.

Disse to nøkkelordene kan ikke byttes ut!

3. Kaste i Java

La oss ta en titt på et grunnleggende eksempel med å kaste et unntak fra metoden.

Tenk deg først at vi skriver en enkel kalkulator. En av de grunnleggende aritmetiske operasjonene er divisjon. På grunn av dette ble vi bedt om å implementere denne funksjonen:

offentlig dobbeltdeling (dobbel a, dobbel b) {return a / b; }

Fordi vi ikke kan dele med null, må vi legge til noen endringer i vår eksisterende kode. Virker som det er et godt øyeblikk for å heve et unntak.

La oss gjøre dette:

offentlig dobbel divisjon (dobbelt a, dobbelt b) {hvis (b == 0) {kast nytt ArithmeticException ("Divider kan ikke være lik null!"); } returnere a / b; }

Som du kan se, har vi brukt Aritmetisk unntak passer perfekt til våre behov. Vi kan passere en singel String konstruktørparameter som er unntaksmelding.

3.1. God praksis

Vi bør alltid foretrekke det mest spesifikke unntaket. Vi må finne en klasse som passer best for vår eksepsjonelle begivenhet. Kast for eksempel NumberFormatException i stedet for IllegalArgumentException. Vi bør unngå å kaste et uspesifikt Unntak.

For eksempel er det en Heltall klasse i java.lang pakke. La oss ta en titt på erklæringen fra fabrikkmetoden:

public static Integer valueOf (String s) kaster NumberFormatException 

Det er en statisk fabrikkmetode som skaper Heltall instans fra String. Ved feil inngang String, vil metoden kaste NumberFormatException.

En god idé er å definere vårt eget, mer beskrivende unntak. I vår Kalkulator klasse som kan være for eksempel DivideByZeroException.

La oss ta en titt på implementering av eksempler:

offentlig klasse DivideByZeroException utvider RuntimeException {public DivideByZeroException (strengmelding) {super (melding); }}

3.2. Innpakning av et eksisterende unntak

Noen ganger ønsker vi å pakke et eksisterende unntak inn i unntaket som er definert av oss.

La oss begynne med å definere vårt eget unntak:

offentlig klasse DataAcessException utvider RuntimeException {public DataAcessException (strengmelding, kastbar årsak) {super (melding, årsak); }}

Konstruktøren tar to parametere: unntaksmelding og en årsak, som kan være hvilken som helst underklasse av Kastbar.

La oss skrive en falsk implementering for findAll () funksjon:

public List findAll () kaster SQLException {throw new SQLException (); }

Nå i SimpleService la oss kalle en depotfunksjon, som kan resultere i SQLE unntak:

public void wrappingException () {try {personRepository.findAll (); } catch (SQLException e) {throw new DataAccessException ("SQL Exception", e); }}

Vi kaster på nytt SQLException innpakket i vårt eget unntak kalt DataAccessException. Alt bekreftes av følgende test:

@Test ugyldig nårSQLExceptionIsThrown_thenShouldBeRethrownWithWrappedException () {assertThrows (DataAccessException.class, () -> simpleService.wrappingException ()); }

Det er to grunner til å gjøre dette. Først og fremst bruker vi unntaksinnpakning, fordi resten av koden ikke trenger å vite om alle mulige unntak i systemet.

Også komponenter på høyere nivå trenger ikke å vite om komponenter på bunnnivå, og heller ikke unntakene de kaster.

3.3. Multi-Catch med Java

Noen ganger kan metodene vi bruker kaste mange forskjellige unntak.

La oss ta en titt på mer omfattende prøvefangstblokk:

prøv {tryCatch.execute (); } fange (ConnectionException | SocketException ex) {System.out.println ("IOException"); } fange (Unntak ex) {System.out.println ("Generelt unntak"); }

De henrette metoden kan kaste tre unntak: SocketException, ConnectionException, Unntak. Den første fangstblokken vil fange ConnectionException eller SocketException. Den andre fangstblokken ville fange Unntak eller annen underklasse av Unntak. Husk at vi bør alltid fange et mer detaljert unntak først.

Vi kan bytte rekkefølgen på fangstblokkene våre. Da ville vi aldri fange SocketException og ConnectionException fordi alt vil gå i fangsten med Unntak.

4. Kaster i Java

Vi legger til kaster til metodedeklarasjonen.

La oss ta en titt på en av de forrige metodedeklarasjonene våre:

public static void execute () kaster SocketException, ConnectionException, Exception

Metoden kan gi flere unntak. De skilles med komma ved slutten av en metodedeklarasjon. Vi kan sette begge, avmerkede og ukontrollerte unntak i kaster. Vi har beskrevet forskjellen mellom dem nedenfor.

4.1. Merkede og ukontrollerte unntak

Et avkrysset unntak betyr at det er sjekket på kompileringstidspunktet. Merk at vi må håndtere dette unntaket. Ellers må en metode spesifisere et unntak ved å bruke kaster nøkkelord.

De vanligste kontrollerte unntakene er IOException, FileNotFoundException, ParseException. FileNotFoundException kan kastes når vi lager FileInputStream fra Fil.

Det er et kort eksempel:

Filfil = ny fil ("not_existing_file.txt"); prøv {FileInputStream stream = new FileInputStream (file); } fange (FileNotFoundException e) {e.printStackTrace (); }

Vi kan unngå å bruke prøvefangstblokk ved å legge til kaster til metodedeklarasjonen:

privat statisk tomrom uncheckedException () kaster FileNotFoundException {File file = new File ("not_existing_file.txt"); FileInputStream stream = ny FileInputStream (fil); }

Dessverre må en høyere funksjon fortsatt håndtere dette unntaket. Ellers må vi sette dette unntaket i metodedeklarasjon med kaster nøkkelord.

Som det motsatte, ukontrollerte unntak blir ikke sjekket på kompileringstidspunktet.

De vanligste ukontrollerte unntakene er: ArrayIndexOutOfBoundsException, IllegalArgumentException, NullPointerException.

Uavmerkede unntak kastes i løpet av kjøretiden. Følgende kode vil kaste a NullPointerException. Sannsynligvis er det et av de vanligste unntakene i Java.

Å ringe en metode på en nullreferanse vil resultere i dette unntaket:

public void runtimeNullPointerException () {Streng a = null; a.lengde (); }

La oss verifisere denne oppførselen i testen:

@Test ugyldig nårCalled_thenNullPointerExceptionIsThrown () {assertThrows (NullPointerException.class, () -> simpleService.runtimeNullPointerException ()); }

Husk at denne koden og testen ikke har noen mening. Det er bare for læringsformål å forklare unntak for kjøretid.

I Java, hver underklasse av Feil og RuntimeException er et ukontrollert unntak. Et avmerket unntak er alt annet under Kastbar klasse.

5. Konklusjon

I denne artikkelen har vi diskutert forskjellen mellom to Java-nøkkelord: kaste og kaster. Vi har gått gjennom den grunnleggende bruken og snakket litt om god praksis. Så har vi snakket om sjekket og ukontrollerte unntak.

Som alltid kan kildekoden bli funnet på GitHub.

Hvis du vil gå dypere inn i Unntakshåndtering i Java, kan du ta en titt på artikkelen vår om Java-unntak.