Drie soorten uitzonderingen op Java

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 te hebben programma's die ze met tegenzin accepteren om de prijs te betalen voor software die vrijwel zeker ten minste één fout bevat het. 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.

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 je kijkt naar de FileReader-constructordefinitie in de Java-API u zult de methodehandtekening zien:

openbare FileReader (String bestandsnaam) gooit FileNotFoundException.

Zoals u kunt zien, stelt de constructeur specifiek dat de FileReader constructor kan een FileNotFoundException. Dit is logisch omdat het zeer waarschijnlijk is dat de bestandsnaam String zal van tijd tot tijd verkeerd zijn. Kijk naar de volgende code:

openbare statische leegte main (String [] args) { FileReader fileInput = null; // Open het invoerbestand. fileInput = nieuwe FileReader ("Untitled.txt"); }

Syntactisch zijn de verklaringen correct, maar deze code zal nooit worden gecompileerd. De compiler kent de FileReader constructor kan een FileNotFoundException en het is aan de aanroepende code om deze uitzondering af te handelen. Er zijn twee keuzes: ten eerste kunnen we de uitzondering van onze methode doorgeven door een op te geven gooit clausule ook:

public static void main (String [] args) gooit FileNotFoundException { FileReader fileInput = null; // Open het invoerbestand. fileInput = nieuwe FileReader ("Untitled.txt"); }

Of we kunnen eigenlijk omgaan met de uitzondering:

openbare statische leegte main (String [] args) { FileReader fileInput = null; proberen. { // Open het invoerbestand. fileInput = nieuwe FileReader ("Untitled.txt"); } vangen (FileNotFoundException ex) { // vertel de gebruiker om het bestand te gaan zoeken. } }

Goed geschreven Java-applicaties moeten bestand zijn tegen gecontroleerde uitzonderingen.

De tweede soort uitzondering staat bekend als de fout. Bij een uitzondering treedt de JVM zal een uitzonderingsobject creëren. Deze objecten komen allemaal voort uit de Gooi klasse. De Gooi klasse heeft twee subklassen: Fout en Uitzondering. De Fout class geeft een uitzondering aan waar een applicatie waarschijnlijk niet mee om kan gaan.

Deze uitzonderingen worden als zeldzaam beschouwd. De JVM kan bijvoorbeeld onvoldoende bronnen hebben omdat de hardware niet alle processen aankan waarmee deze te maken heeft. Het is mogelijk dat de applicatie de fout opvangt om de gebruiker op de hoogte te stellen, maar meestal zal de applicatie moeten sluiten totdat het onderliggende probleem is opgelost.

EEN runtime-uitzondering gebeurt simpelweg 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 veroorzaakte dat een methode werd aangeroepen met een null waarde. Of een willekeurig aantal fouten die een programmeur kan maken. Maar dat is goed, we zien deze uitzonderingen door uitgebreide tests, toch?

Fouten en runtime-uitzonderingen vallen in de categorie van niet-gecontroleerde uitzonderingen.