Tre typer undtagelser i Java

Fejl er både brugerne og programmørernes bane. Udviklere ønsker tydeligvis ikke, at deres programmer falder ned ved hver tur, og brugerne er nu så vant til at have fejl i programmer, som de modvilligt accepterer at betale prisen for software, der næsten helt sikkert har mindst en fejl i det. Java er designet til at give programmereren en sportslig chance i at designe en fejlfri applikation. Der er undtagelser, som programmereren ved, er en mulighed, når en applikation interagerer med en ressource eller en bruger, og disse undtagelser kan håndteres. Desværre er der undtagelser, som programmereren ikke kan kontrollere eller blot overser. Kort sagt er alle undtagelser ikke skabt lige, og der er derfor flere typer, som en programmerer kan tænke på.

En undtagelse er en begivenhed, der får programmet til at være ude af stand til at flyde i dens tilsigtede udførelse. Der er tre typer undtagelser - den markerede undtagelse, fejlen og runtime-undtagelsen.

Kontrollerede undtagelser er undtagelser, som en Java-applikation skal kunne klare. For eksempel, hvis en applikation læser data fra en fil, skal den kunne håndtere

For at tage dette eksempel et skridt videre. Lad os sige, at vi bruger FileReader klasse for at læse en karakterfil. Hvis du kigger på FileReader konstruktørdefinition i Java api du vil se dets metodesignatur:

public FileReader (String fileName) kaster FileNotFoundException.

Som du kan se, udtaler konstruktøren specifikt, at FileReader konstruktør kan kaste en FileNotFoundException. Dette giver mening, da det er meget sandsynligt, at filnavn Streng vil være forkert fra tid til anden. Se på følgende kode:

public static void main (String [] args) { FileReader fileInput = null; // Åbn inputfilen. fileInput = new FileReader ("Untitled.txt"); }

Syntaktisk er udsagnene korrekte, men denne kode samles aldrig. Kompilatoren kender FileReader konstruktør kan kaste en FileNotFoundException og det er op til opkaldskoden at håndtere denne undtagelse. Der er to valg - for det første kan vi videregive undtagelsen fra vores metode ved at specificere en kaster klausul også:

public static void main (String [] args) kaster FileNotFoundException { FileReader fileInput = null; // Åbn inputfilen. fileInput = new FileReader ("Untitled.txt"); }

Eller vi kan faktisk håndtere med undtagelsen:

public static void main (String [] args) { FileReader fileInput = null; prøve. { // Åbn inputfilen. fileInput = new FileReader ("Untitled.txt"); } fangst (FileNotFoundException ex) { // bed brugeren om at gå og finde filen. } }

Velskrevne Java-applikationer skal være i stand til at klare kontrollerede undtagelser.

Den anden type undtagelse er kendt som fejlen. Når der sker en undtagelse, JVM opretter et undtagelsesobjekt. Disse genstande stammer alle fra Throwable klasse. Det Throwable klasse har to hovedunderklasser - Fejl og Undtagelse. Det Fejl klasse betegner en undtagelse, som en applikation sandsynligvis ikke kan håndtere.

Disse undtagelser betragtes som sjældne. F.eks. Kan JVM løbe tør for ressourcer på grund af, at hardwaren ikke er i stand til at klare alle de processer, den har at gøre med. Det er muligt for applikationen at fange fejlen for at underrette brugeren, men typisk bliver applikationen nødt til at lukke, indtil det underliggende problem er løst.

EN undtagelse af runtime opstår simpelthen fordi programmereren har begået en fejl. Du har skrevet koden, det hele ser godt ud for kompilatoren, og når du går til at køre koden, falder den ned, fordi den forsøgte at få adgang til et element i en matrix, der ikke findes, eller en logisk fejl forårsagede, at en metode blev kaldt med en nul værdi. Eller ethvert antal fejl, en programmerer kan begå. Men det er okay, vi finder disse undtagelser ved udtømmende test, ikke?

Fejl og kørselsundtagelser falder i kategorien af ​​ikke-markerede undtagelser.