Unntak: avmerket, uavmerket og tilpasset

Hei! I siste leksjon ble vi kjent med unntak i Java-språket, og så eksempler på hvordan man kan jobbe med dem. I dag skal vi ta en dypere titt på strukturen til unntak, og lære å skrive våre egne unntak :)

Typer unntak

Som vi sa tidligere, er det mange unntak i Java, nesten 400! Men de er alle delt inn i grupper, så det er ganske enkelt å huske dem. Slik ser det ut: Alle unntak har en felles stamfar i Throwableklassen. To hovedgrupper er avledet fra det: unntak ( Unntak ) og feil ( Feil ). Feil - Dette representerer en kritisk kjøretidsfeil relatert til driften av den virtuelle Java-maskinen. I de fleste tilfeller trenger ikke feil å håndteres, siden det indikerer noen alvorlige feil i koden. De mest kjente av disse er StackOverflowError (dette oppstår for eksempel når en metode kaller seg uendelig) og OutOfMemoryError(dette skjer når det ikke er nok minne til å lage nye objekter). Som du kan se, i disse situasjonene, er det vanligvis ingenting å håndtere under kjøring: koden er rett og slett skrevet feil og må omarbeides. Unntak - Dette representerer, vel, et unntak: en eksepsjonell, ikke-planlagt situasjon som oppstår mens programmet kjører. De er ikke så alvorlige som feil, men de krever fortsatt vår oppmerksomhet. Alle unntak er delt inn i 2 typer: avmerket og ukontrollert . Alle avmerkede unntak er avledet fra Exceptionklassen. Hva betyr "sjekket"? Vi hentydet til dette i forrige leksjon: "Java-kompilatoren kjenner derfor til de vanligste unntakene og situasjonene der de kan forekomme." For eksempel vet den at hvis koden leser data fra en fil, kan filen lett ikke eksistere. Og det er mange slike situasjoner (som den kan utlede). Følgelig sjekker kompilatoren vår kode på forhånd for tilstedeværelsen av disse potensielle unntakene. Hvis den finner dem, kompilerer den ikke koden før vi har håndtert dem eller kastet dem på nytt. Den andre typen unntak er "ukontrollert". De er avledet fra RuntimeExceptionklassen. Hvordan er de forskjellige fra sjekkede unntak? Det ser ut til at det også er mange forskjellige klasser avledet fraRuntimeException(som beskriver kjøretidsunntak). Forskjellen er at kompilatoren ikke forutser disse feilene. Det ser ut til å si: "Da koden ble skrevet, fant jeg ikke noe mistenkelig, men noe gikk galt mens den kjørte. Tilsynelatende er det feil i koden!" Og dette er faktisk sant. Ukontrollerte unntak er oftest et resultat av programmeringsfeil. Og kompilatoren kan åpenbart ikke forutse alle mulige dårlige situasjoner folk kan skape med egne hender. :) Derfor sjekker den ikke om slike unntak håndteres i koden vår. Du har allerede støtt på flere ukontrollerte unntak:

• Et aritmetisk unntak oppstår ved deling på null
• Et ArrayIndexOutOfBoundsException oppstår når du prøver å få tilgang til en posisjon utenfor arrayen.

Selvfølgelig kan du forestille deg at Javas skapere kunne ha innført obligatorisk unntakshåndtering, men i dette tilfellet ville koden være for komplisert. For enhver divisjonsoperasjon, må du skrive en try-catchblokk for å sjekke om du ved et uhell delte på null? Hver gang du fikk tilgang til en matrise, måtte du skrive en try-catchblokk for å sjekke om indeksen din var utenfor grensene. Alt ville være spaghettikode og ville være fullstendig uleselig. Det er fornuftig at denne ideen ble forlatt. Som et resultat trenger ikke ukontrollerte unntak å håndteres i try-catchblokker eller kastes på nytt (selv om dette er teknisk mulig, som med Error).

Hvordan kaste ditt eget unntak

Selvfølgelig kan Javas skapere ikke forutse enhver eksepsjonell situasjon som kan oppstå i programmer. Det er for mange programmer i verden, og de er for mangfoldige. Men dette er ikke noe å bekymre seg for, fordi du kan lage ditt eget unntak, om nødvendig. Dette er veldig enkelt å gjøre. Alt du trenger å gjøre er å lage din egen klasse. Du bør være sikker på at navnet slutter med "Unntak". Kompilatoren krever ikke dette, men andre programmerere som leser koden din vil umiddelbart forstå at det er en unntaksklasse. I tillegg, angi at klassen er arvet fra Exceptionklassen (kompilatoren krever dette). Anta for eksempel at vi har en Dogklasse. Vi kan gå tur med hunden ved hjelp avwalk()metode. Men før vi gjør det, må vi sjekke om kjæledyret vårt har på seg halsbånd, bånd og snute. Hvis noe av dette utstyret mangler, kaster vi vårt eget unntak: DogIsNotReadyException . Koden ser slik ut:

public class DogIsNotReadyException extends Exception {

   public DogIsNotReadyException(String message) {
       super(message);
   }
}

For å indikere at klassen er et unntak, må du skrive " extends Exception " etter klassenavnet (dette betyr "klassen er avledet fra Exception-klassen"). I konstruktøren kaller vi ganske enkelt klassekonstruktøren Exceptionmed String -meldingen (hvis unntaket forekommer, vil vi vise meldingen, en beskrivelse av feilen, til brukeren). Slik ser dette ut i klassekoden vår:

public class Dog {

   String name;
   boolean isCollarPutOn;
   boolean isLeashPutOn;
   boolean isMuzzlePutOn;


   public Dog(String name) {
       this.name = name;
   }

   public static void main(String[] args) {

   }

   public void putCollar() {

       System.out.println("The collar is on!");
       this.isCollarPutOn = true;
   }

   public void putLeash() {

       System.out.println("The leash is on!");
       this.isLeashPutOn = true;
   }

   public void putMuzzle() {
       System.out.println("The muzzle is on!");
       this.isMuzzlePutOn = true;
   }

   public void walk() throws DogIsNotReadyException {

   System.out.println("We're getting ready for a walk!");
   if (isCollarPutOn && isLeashPutOn && isMuzzlePutOn) {
       System.out.println("Hooray, let's go for a walk! " + name + " is very happy!");
   } else {
       throw new DogIsNotReadyException(name + " is not ready for a walk! Check the gear!");
   }
 }

}

Nå walk()gir metoden vår en DogIsNotReadyException . Dette gjøres med søkeordet kast. Som vi sa tidligere, er et unntak et objekt. Så når et unntak oppstår (hunden mangler noe) i metoden vår, lager vi et nytt DogIsNotReadyExceptionobjekt og kaster det ved å bruke nøkkelordet throw. Vi legger til " kaster DogIsNotReadyException " til metodedeklarasjonen. Med andre ord, nå er kompilatoren klar over at å kalle metoden walk()kan bli en eksepsjonell situasjon. Følgelig må dette unntaket håndteres hvis vi kaller denne metoden et sted i programmet vårt. La oss prøve å gjøre dette i main()metoden:

public static void main(String[] args) {
  
   Dog dog = new Dog("Buddy");
   dog.putCollar();
   dog.putMuzzle();
   dog.walk();// Unhandled exception: DogIsNotReadyException
}

Dette vil ikke kompilere. Unntaket håndteres ikke! Vi pakker inn koden vår i en try-catchblokk for å håndtere unntaket:

public static void main(String[] args) {

   Dog dog = new Dog("Buddy");
   dog.putCollar();
   dog.putMuzzle();
   try {
       dog.walk();
   } catch (DogIsNotReadyException e) {
       System.out.println(e.getMessage());
       System.out.println("Checking the gear! Is the collar on? " + dog.isCollarPutOn + "\r\n Is the leash on? "
       + dog.isLeashPutOn + "\r\n Is the muzzle on? " + dog.isMuzzlePutOn);
   }
}

La oss nå se på konsollutgangen: Kragen er på! Snuten er på! Vi gjør oss klare for tur! Buddy er ikke klar for tur! Sjekk utstyret! Sjekker utstyret! Er kragen på? sant Er båndet på? falsk Er snuten på? sant Se hvor mye mer informativ konsollutgangen var! Vi ser hvert steg tatt i programmet; vi ser hvor feilen oppsto, og vi kan også umiddelbart se nøyaktig hva hunden vår mangler. :) Og slik lager du dine egne unntak. Som du kan se, er det ikke noe komplisert med det. Og selv om Javas skapere ikke gadd å inkludere et spesielt unntak for dårlig utstyrte hunder i språket, har vi rettet oppsynet deres. :)