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 att de på ett modigt sätt accepterar att betala priset för programvara som nästan säkert kommer att ha minst ett fel i det. Java är utformat 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 därför finns det 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 FileNotFoundException
. Det finns trots allt ingen garanti för att den förväntade filen kommer att vara där den ska vara. Allt kan hända på filsystemet, vilket en applikation inte skulle ha någon aning om.
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-konstruktionsdefinitionen i Java-api ser du dess 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 inputfil 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 inputfil fileInput = new FileReader ("Untitled.txt");
Eller så kan vi faktiskt hantera med undantag:
public static void main (String [] args) FileReader fileInput = null; försök // Öppna inmatningsfilen fileInput = new FileReader ("Untitled.txt"); catch (FileNotFoundException ex) // berätta för 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 skapar JVM 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.
Ett undantag för körning 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 den över eftersom den försökte få åtkomst till ett element i en matris som inte finns eller ett logikfel orsakade att en metod kallades med ett nollvärde. Eller vilket antal misstag en programmerare kan göra. Men det är okej, vi ser dessa undantag genom uttömmande tester, rätt?