Tre typer av undantag i Java

Fel är både användare och programmerare. Utvecklare vill uppenbarligen inte att deras program faller ner vid varje tur och användare är nu så vana att ha fel i program som de motvilligt accepterar att betala priset för programvara som nästan säkert kommer att ha minst ett fel i den. Java är utformad för att ge programmeraren en sportslig chans att designa en felfri applikation. Det finns undantag som programmeraren kommer att veta är en möjlighet när en applikation interagerar med en resurs eller en användare och dessa undantag kan hanteras. Tyvärr finns det undantag som programmeraren inte kan kontrollera eller helt enkelt förbiser. Kort sagt, alla undantag skapas inte lika och det finns därför flera typer för en programmerare att tänka på.

Ett undantag är en händelse som gör att programmet inte kan flöda i den avsedda exekveringen. Det finns tre typer av undantag - det kontrollerade undantaget, felet och runtime-undantaget.

Kontrollerade undantag är undantag som en Java-applikation ska kunna hantera. Om en applikation till exempel läser data från en fil ska den kunna hantera

För att ta detta exempel ett steg längre. Låt oss säga att vi använder Filereader klass för att läsa en teckenfil. Om du tittar på FileReader konstruktörs definition i Java api du kommer att se dets metodsignatur:

public FileReader (String fileName) kastar FileNotFoundException.

Som ni ser konstruktören uttryckligen säger att Filereader konstruktör kan kasta en FileNotFoundException. Detta är vettigt eftersom det är mycket troligt att filnamn Strängen kommer att vara fel då och då. Titta på följande kod:

public static void main (String [] args) { FileReader fileInput = null; // Öppna inmatningsfilen. fileInput = new FileReader ("Untitled.txt"); }

Syntaktiskt är uttalandena korrekta men den här koden kommer aldrig att sammanställas. Kompilatorn känner till Filereader konstruktör kan kasta en FileNotFoundException och det är upp till anropskoden att hantera detta undantag. Det finns två val - för det första kan vi vidarebefordra undantaget från vår metod genom att ange a kastar klausul också:

public static void main (String [] args) kastar FileNotFoundException { FileReader fileInput = null; // Öppna inmatningsfilen. fileInput = new FileReader ("Untitled.txt"); }

Eller så kan vi faktiskt hantera med undantag:

public static void main (String [] args) { FileReader fileInput = null; Prova. { // Öppna inmatningsfilen. fileInput = new FileReader ("Untitled.txt"); } fånga (FileNotFoundException ex) { // ber användaren att gå och hitta filen. } }

Välskrivna Java-applikationer bör kunna hantera kontrollerade undantag.

Den andra typen av undantag kallas felet. När ett undantag inträffar JVM skapar ett undantagsobjekt. Dessa objekt härrör alla från Throwable klass. De Throwable klass har två huvudunderklasser— Fel och Undantag. De Fel klass betecknar ett undantag som en applikation troligen inte kan hantera.

Dessa undantag anses vara sällsynta. Till exempel kan det hända att JVM går tom för resurser på grund av att hårdvaran inte kan hantera alla processer den måste hantera. Det är möjligt för applikationen att fånga felet för att meddela användaren men vanligtvis måste applikationen stängas tills det underliggande problemet har hanterats.

EN runtime-undantag inträffar helt enkelt på grund av att programmeraren har gjort ett misstag. Du har skrivit koden, det ser bra ut för kompilatorn och när du går för att köra koden faller det för det försökte komma åt ett element i en array som inte finns eller ett logikfel orsakade att en metod kallades med en noll värde. Eller vilket antal misstag en programmerare kan göra. Men det är okej, vi ser dessa undantag genom uttömmande tester, eller hur?

Fel och Runtime-undantag faller i kategorin av okontrollerade undantag.