Tre typer unntak i Java

click fraud protection

Feil er både brukere og programmerere. Utviklere ønsker tydeligvis ikke at programmene deres faller over hver tur og brukerne er nå så vant til å ha feil i programmer som de motvillig godtar å betale prisen for programvare som nesten helt sikkert vil ha minst en feil i den. Java er designet for å gi programmereren en sportslig sjanse til å designe en feilfri applikasjon. Det er unntak som programmereren vil vite er en mulighet når en applikasjon samhandler med en ressurs eller en bruker, og disse unntakene kan håndteres. Dessverre er det unntak programmereren ikke kan kontrollere eller bare overser. Kort sagt, alle unntak er ikke skapt like, og det er derfor flere typer for en programmerer å tenke på.

Et unntak er en hendelse som gjør at programmet ikke kan flyte i den tiltenkte utførelsen. Det er tre typer unntak - det kontrollerte unntaket, feilen og runtime-unntaket.

Det sjekket unntaket

Sjekkede unntak er unntak som en Java-applikasjon skal kunne takle. Hvis en applikasjon for eksempel leser data fra en fil, skal den kunne håndtere den

instagram viewer
FileNotFoundException. Det er tross alt ingen garanti for at den forventede filen kommer til å være der den skal. Alt kan skje på filsystemet, noe en applikasjon ikke har noen anelse om.

For å ta dette eksemplet et skritt videre. La oss si at vi bruker Filereader klasse for å lese en karakterfil. Hvis du ser på FileReader konstruktørdefinisjon i Java api du vil se det er metodesignatur:

public FileReader (String fileName) kaster FileNotFoundException.

Som du kan se, sier konstruktøren spesielt at Filereader konstruktør kan kaste en FileNotFoundException. Dette er fornuftig da det er veldig sannsynlig at filnavn Streng vil være feil fra tid til annen. Se på følgende kode:

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

Syntaktisk er utsagnene riktige, men denne koden vil aldri samles. Kompilatoren kjenner Filereader konstruktør kan kaste en FileNotFoundException og det er opp til anropskoden å håndtere dette unntaket. Det er to valg - for det første kan vi gi unntaket videre fra metoden vår ved å spesifisere en kaster klausul også:

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

Eller vi kan faktisk håndtere med unntaket:

public static void main (String [] args) { FileReader fileInput = null; prøve. { // Åpne inndatafilen. fileInput = new FileReader ("Untitled.txt"); } fangst (FileNotFoundException eks) { // be brukeren gå og finne filen. } }

Velskrevne Java-applikasjoner skal kunne takle sjekket unntak.

feil

Den andre typen unntak er kjent som feilen. Når et unntak inntreffer JVM vil opprette et unntaksobjekt. Disse gjenstandene stammer fra Throwable klasse. De Throwable klasse har to hovedunderklasser - Feil og Unntak. De Feil klasse betegner et unntak som det ikke er sannsynlig at en applikasjon kan håndtere.

Disse unntakene anses som sjeldne. For eksempel kan det hende at JVM går tom for ressurser på grunn av at maskinvaren ikke klarer å takle alle prosessene den må håndtere. Det er mulig for applikasjonen å fange opp feilen for å varsle brukeren, men vanligvis må applikasjonen lukkes til det underliggende problemet blir håndtert.

Runtime-unntak

EN unntak av kjøretid oppstår rett og slett fordi programmereren har gjort en feil. Du har skrevet koden, det hele ser bra ut for kompilatoren, og når du går for å kjøre koden, faller det fordi det prøvde å få tilgang til et element i en matrise som ikke eksisterer eller en logisk feil forårsaket at en metode ble kalt med en null verdi. Eller et antall feil en programmerer kan gjøre. Men det er greit, vi ser disse unntakene ved uttømmende tester, ikke sant?

Feil og kjøretids unntak faller i kategorien unntak som ikke er merket.

instagram story viewer