Undtagelser: markeret, umarkeret og tilpasset

Hej! I sidste lektion stiftede vi bekendtskab med undtagelser i Java-sproget, og så eksempler på hvordan man kan arbejde med dem. I dag vil vi tage et dybere kig på strukturen af ​​undtagelser og lære at skrive vores egne undtagelser :)

Typer af undtagelser

Som vi sagde tidligere, er der mange undtagelser i Java, næsten 400! Men de er alle opdelt i grupper, så det er ret nemt at huske dem. Sådan ser det ud: Alle undtagelser har en fælles forfader i Throwableklassen. To hovedgrupper er afledt af det: undtagelser ( undtagelse ) og fejl ( fejl ). Fejl - Dette repræsenterer en kritisk køretidsfejl relateret til driften af ​​den virtuelle Java-maskine. I de fleste tilfælde behøver fejl ikke at blive håndteret, da det indikerer nogle alvorlige fejl i koden. De mest berømte af disse er StackOverflowError (dette opstår f.eks. når en metode kalder sig selv uendeligt) og OutOfMemoryError(dette sker, når der ikke er nok hukommelse til at oprette nye objekter). Som du kan se, er der i disse situationer normalt absolut intet at håndtere under kørsel: koden er simpelthen skrevet forkert og skal omarbejdes. Undtagelse - Dette repræsenterer, ja, en undtagelse: en usædvanlig, uplanlagt situation, der opstår, mens programmet kører. De er ikke så alvorlige som fejl, men de kræver stadig vores opmærksomhed. Alle undtagelser er opdelt i 2 typer: markeret og umarkeret . Alle markerede undtagelser er afledt fra Exceptionklassen. Hvad betyder "tjekket"? Vi hentydede til dette i sidste lektion: "Java-kompileren kender derfor de mest almindelige undtagelser og de situationer, hvor de kan forekomme." For eksempel ved den, at hvis koden læser data fra en fil, kan filen nemt ikke eksistere. Og der er mange sådanne situationer (som den kan udlede). Derfor kontrollerer compileren vores kode på forhånd for tilstedeværelsen af ​​disse potentielle undtagelser. Hvis den finder dem, kompilerer den ikke koden, før vi har håndteret dem eller smidt dem igen. Den anden type undtagelse er "ikke markeret". De stammer fra RuntimeExceptionklassen. Hvordan adskiller de sig fra kontrollerede undtagelser? Det ser ud til, at der også er masser af forskellige klasser, der stammer fraRuntimeException(som beskriver runtime undtagelser). Forskellen er, at compileren ikke forudser disse fejl. Det lader til at sige: "Da koden blev skrevet, fandt jeg ikke noget mistænkeligt, men noget gik galt, mens den kørte. Der er åbenbart fejl i koden!" Og det er sandelig sandt. Ikke-markerede undtagelser er oftest resultatet af programmørfejl. Og compileren kan åbenbart ikke forudse enhver mulig dårlig situation, som folk kan skabe med deres egne hænder. :) Derfor tjekker den ikke, om sådanne undtagelser håndteres i vores kode. Du har allerede stødt på flere umarkerede undtagelser:

• En aritmetisk undtagelse opstår, når man dividerer med nul
• En ArrayIndexOutOfBoundsException opstår, når du forsøger at få adgang til en position uden for arrayet.

Selvfølgelig kan du forestille dig, at Javas skabere kunne have indført obligatorisk undtagelseshåndtering, men i dette tilfælde ville koden være for kompliceret. For enhver divisionsoperation, skal du skrive en try-catchblok for at kontrollere, om du ved et uheld har divideret med nul? Hver gang du åbnede et array, skulle du skrive en try-catchblok for at kontrollere, om dit indeks var uden for grænserne. Alt ville være spaghetti-kode og ville være fuldstændig ulæseligt. Det giver mening, at denne idé blev opgivet. Som følge heraf behøver umarkerede undtagelser ikke at blive håndteret i try-catchblokke eller smidt igen (selvom dette er teknisk muligt, som med Error).

Sådan kaster du din egen undtagelse

Selvfølgelig kan Javas skabere ikke forudse enhver ekstraordinær situation, der kan opstå i programmer. Der er for mange programmer i verden, og de er for forskellige. Men dette er ikke noget at bekymre sig om, for du kan oprette din egen undtagelse, hvis det er nødvendigt. Dette er meget nemt at gøre. Alt du skal gøre er at oprette din egen klasse. Du skal være sikker på, at dens navn ender med "undtagelse". Compileren kræver ikke dette, men andre programmører, der læser din kode, vil straks forstå, at det er en undtagelsesklasse. Derudover skal du angive, at klassen er nedarvet fra Exceptionklassen (kompileren kræver dette). Antag for eksempel, at vi har en Dogklasse. Vi kan gå tur med hunden ved hjælp afwalk()metode. Men før vi gør det, skal vi tjekke, om vores kæledyr har halsbånd, snor og næseparti på. Hvis noget af dette gear mangler, kaster vi vores egen undtagelse: DogIsNotReadyException . Dens kode ser sådan ud:

public class DogIsNotReadyException extends Exception {

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

For at indikere, at klassen er en undtagelse, skal du skrive " extends Exception " efter klassenavnet (dette betyder "klassen er afledt af Exception-klassen"). I konstruktøren kalder vi simpelthen klassekonstruktøren Exceptionmed String- meddelelsen (hvis undtagelsen forekommer, vil vi vise beskeden, en beskrivelse af fejlen, til brugeren). Sådan ser det ud i vores klassekode:

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!");
   }
 }

}

Nu walk()afgiver vores metode en DogIsNotReadyException . Dette gøres med søgeordet throw. Som vi sagde tidligere, er en undtagelse et objekt. Så når der opstår en undtagelse (hunden mangler noget) i vores metode, opretter vi et nyt DogIsNotReadyExceptionobjekt og kaster det med nøgleordet throw. Vi tilføjer " throws DogIsNotReadyException " til metodedeklarationen. Med andre ord, nu er compileren klar over, at kald af walk()metoden kan blive til en usædvanlig situation. Derfor skal denne undtagelse håndteres, hvis vi kalder denne metode et sted i vores program. Lad os prøve at gø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. Undtagelsen håndteres ikke! Vi pakker vores kode i en try-catchblok for at håndtere undtagelsen:

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);
   }
}

Lad os nu se på konsoludgangen: Halsbåndet er på! Munden er på! Vi gør klar til en gåtur! Buddy er ikke klar til en gåtur! Tjek gearet! Tjekker gearet! Er kraven på? sandt Er snoren på? falsk Er næsepartiet på? sandt Se hvor meget mere informativt konsoludgangen var! Vi ser hvert skridt taget i programmet; vi ser hvor fejlen er opstået, og vi kan også med det samme se præcis hvad vores hund mangler. :) Og sådan skaber man sine egne undtagelser. Som du kan se, er der ikke noget kompliceret ved det. Og selvom Javas skabere ikke gad at inkludere i sproget en særlig undtagelse for dårligt udstyrede hunde, har vi rettet deres tilsyn. :)