Drie soorten uitzonderingen op Java
Share
Fouten zijn de vloek van zowel gebruikers als programmeurs. Ontwikkelaars willen natuurlijk niet dat hun programma's bij elke beurt omvallen en gebruikers zijn nu zo gewend om fouten in programma's te hebben dat ze met tegenzin accepteren dat ze de prijs betalen voor software die vrijwel zeker minstens één fout zal bevatten. Java is ontworpen om de programmeur een sportieve kans te geven bij het ontwerpen van een foutloze applicatie. Er zijn uitzonderingen waarvan de programmeur weet dat het een mogelijkheid is wanneer een toepassing interactie heeft met een bron of een gebruiker en deze uitzonderingen kunnen worden verwerkt. Helaas zijn er uitzonderingen die de programmeur niet kan controleren of gewoon over het hoofd ziet. Kortom, alle uitzonderingen zijn niet gelijk gemaakt en daarom zijn er verschillende typen waar een programmeur over na kan denken.
Een uitzondering is een gebeurtenis waardoor het programma niet naar behoren kan worden uitgevoerd. Er zijn drie soorten uitzonderingen: de aangevinkte uitzondering, de fout en de runtime-uitzondering.
De gecontroleerde uitzondering
Gecontroleerde uitzonderingen zijn uitzonderingen die een Java-toepassing moet kunnen verwerken. Als een toepassing bijvoorbeeld gegevens uit een bestand leest, moet deze de FileNotFoundException . Er is immers geen garantie dat het verwachte bestand zal zijn waar het zou moeten zijn. Er kan van alles gebeuren op het bestandssysteem, waar een applicatie geen idee van heeft.
Om dit voorbeeld een stap verder te nemen. Laten we zeggen dat we de FileReader klasse om een tekenbestand te lezen. Als u de constructordefinitie van FileReader in de Java-API bekijkt, ziet u de handtekening van de methode:
public FileReader (String fileName) gooit FileNotFoundException Zoals u kunt zien, stelt de constructor specifiek dat de FileReader constructor kan een gooien FileNotFoundException. Dit is logisch omdat het zeer waarschijnlijk is dat de bestandsnaam String zal van tijd tot tijd verkeerd zijn. Bekijk de volgende code:
public static void main (String [] args) FileReader fileInput = null; // Open het invoerbestand fileInput = new FileReader ("Untitled.txt"); Syntactisch zijn de verklaringen correct, maar deze code zal nooit compileren. De compiler kent het FileReader constructor kan een gooien FileNotFoundException en het is aan de roepcode om met deze uitzondering om te gaan. Er zijn twee keuzes - ten eerste kunnen we de uitzondering van onze methode doorgeven door een op te geven worpen clausule ook:
public static void main (String [] args) gooit FileNotFoundException FileReader fileInput = null; // Open het invoerbestand fileInput = new FileReader ("Untitled.txt"); Of we kunnen eigenlijk omgaan met de uitzondering:
public static void main (String [] args) FileReader fileInput = null; probeer // Open het invoerbestand fileInput = new FileReader ("Untitled.txt"); catch (FileNotFoundException ex) // vertel de gebruiker om het bestand te gaan zoeken Goed geschreven Java-toepassingen moeten gecontroleerde uitzonderingen aankunnen.
fouten
Het tweede soort uitzondering staat bekend als de fout. Wanneer een uitzondering optreedt, maakt de JVM een uitzonderingsobject. Deze objecten komen allemaal voort uit de Throwable klasse. De Throwable klasse heeft twee hoofdsubklassen- Fout en Uitzondering. De Fout klasse geeft een uitzondering aan waarmee een toepassing waarschijnlijk niet in staat is.
Deze uitzonderingen worden als zeldzaam beschouwd. De JVM kan bijvoorbeeld te weinig bronnen hebben omdat de hardware niet in staat is om alle processen aan te kunnen waarmee hij te maken heeft. Het is mogelijk dat de toepassing de fout opmerkt om de gebruiker op de hoogte te stellen, maar meestal moet de toepassing worden gesloten totdat het onderliggende probleem is opgelost.
Looptijduitzonderingen
Er is een runtime-uitzondering omdat de programmeur een fout heeft gemaakt. Je hebt de code geschreven, het ziet er allemaal goed uit voor de compiler en wanneer je de code gaat uitvoeren, valt het om omdat het probeerde toegang te krijgen tot een element van een array dat niet bestaat of een logische fout ervoor zorgde dat een methode werd aangeroepen met een nulwaarde. Of een willekeurig aantal fouten die een programmeur kan maken. Maar dat is oké, we zien deze uitzonderingen door grondige tests, toch?
