Spørgsmål om Java-undtagelser Interview (+ svar)

Denne artikel er en del af en serie: • Interviewsspørgsmål om Java Collections

• Spørgsmål om Java Type System Interview

• Java-spørgsmål om samtidige samtaler (+ svar)

• Interviewspørgsmål om Java-klassestruktur og initialisering

• Java 8 interviewspørgsmål (+ svar)

• Hukommelsesstyring i Java Interview-spørgsmål (+ svar)

• Interviews med Java Generics (+ svar)

• Interviewspørgsmål til Java Flow Control (+ svar)

• Java-undtagelsesspørgsmål (+ svar) (nuværende artikel) • Java-kommentarer Interviewspørgsmål (+ svar)

• Top forårssamarbejdsspørgsmål

1. Oversigt

Undtagelser er et vigtigt emne, som enhver Java-udvikler skal være fortrolig med. Denne artikel giver svar på nogle af de spørgsmål, der kan dukke op under et interview.

2. Spørgsmål

Q1. Hvad er en undtagelse?

En undtagelse er en unormal begivenhed, der opstår under udførelsen af ​​et program og forstyrrer den normale strøm af programmets instruktioner.

Q2. Hvad er formålet med kaste og kaste nøgleord?

Det kaster nøgleord bruges til at specificere, at en metode muligvis hæver en undtagelse under dens udførelse. Det håndhæver eksplicit undtagelsesbehandling, når man kalder en metode:

public void simpleMethod () kaster undtagelse {// ...}

Det kaste nøgleord giver os mulighed for at kaste et undtagelsesobjekt for at afbryde den normale strøm af programmet. Dette bruges mest, når et program ikke opfylder en given betingelse:

if (task.isTooComplicated ()) {throw new TooComplicatedException ("Opgaven er for kompliceret"); }

Q3. Hvordan kan du håndtere en undtagelse?

Ved at bruge en prøv-fang-endelig udmelding:

prøv {// ...} fange (ExceptionType1 ex) {// ...} fange (ExceptionType2 ex) {// ...} endelig {// ...}

Kodeblokken, hvor en undtagelse kan forekomme, er vedlagt i a prøve blok. Denne blok kaldes også "beskyttet" eller "beskyttet" kode.

Hvis der forekommer en undtagelse, fangst en blok, der matcher den undtagelse, der kastes, udføres, hvis ikke, alle fangst blokke ignoreres.

Det langt om længe Blok udføres altid efter prøve blokudgange, hvad enten der blev kastet en undtagelse inde i den.

Q4. Hvordan kan du fange flere undtagelser?

Der er tre måder at håndtere flere undtagelser i en kodeblok på.

Den første er at bruge en fangst blok, der kan håndtere alle undtagelsestyper, der smides:

prøv {// ...} fange (Undtagelseseksempel) {// ...}

Du skal huske på, at den anbefalede praksis er at bruge undtagelsesbehandlere, der er så nøjagtige som muligt.

Undtagelsesbehandlere, der er for brede, kan gøre din kode mere udsat for fejl, fange undtagelser, der ikke var forventet, og forårsage uventet adfærd i dit program.

Den anden måde er implementering af flere fangstblokke:

prøv {// ...} fange (FileNotFoundException ex) {// ...} fange (EOFException ex) {// ...}

Bemærk, at hvis undtagelserne har et arvelig forhold; barnetypen skal komme først, og forældertypen senere. Hvis vi ikke gør dette, vil det resultere i en kompileringsfejl.

Den tredje er at bruge en blok med flere fangster:

prøv {// ...} fange (FileNotFoundException | EOFException ex) {// ...}

Denne funktion blev først introduceret i Java 7; reducerer duplikering af kode og gør det lettere at vedligeholde.

Q5. Hvad er forskellen mellem en kontrolleret og en ukontrolleret undtagelse?

En kontrolleret undtagelse skal håndteres inden for en prøve-fangst blokere eller erklæres i en kaster klausul; der henviser til, at det ikke kræves, at en ukontrolleret undtagelse håndteres eller erklæres.

Kontrollerede og ikke-markerede undtagelser er også kendt som henholdsvis kompileringstid og runtime-undtagelser.

Alle undtagelser er markerede undtagelser, undtagen dem, der er angivet med Fejl, RuntimeExceptionog deres underklasser.

Q6. Hvad er forskellen mellem en undtagelse og en fejl?

En undtagelse er en begivenhed, der repræsenterer en tilstand, hvorfra det er muligt at gendanne, mens fejl repræsenterer en ekstern situation, som regel umulig at komme sig fra.

Alle fejl fra JVM er forekomster af Fejl eller en af ​​dens underklasser, de mere almindelige inkluderer, men er ikke begrænset til:

  • OutOfMemoryError - kastet, når JVM ikke kan allokere flere objekter, fordi det er ude af hukommelse, og affaldssamleren ikke var i stand til at stille mere til rådighed
  • StackOverflowError - opstår, når stakpladsen for en tråd er løbet tør, typisk fordi et program gentages for dybt
  • ExceptionInInitializerError - signalerer, at der opstod en uventet undtagelse under evalueringen af ​​en statisk initialisering
  • NoClassDefFoundError - kastes, når klasselæsseren prøver at indlæse definitionen af ​​en klasse og ikke kunne finde den, normalt fordi det kræves klasse filer blev ikke fundet på klassestien
  • Ikke-understøttetClassVersionError - opstår, når JVM forsøger at læse en klasse fil og bestemmer, at versionen i filen ikke understøttes, normalt fordi filen blev genereret med en nyere version af Java

Selvom en fejl kan håndteres med en prøve erklæring, dette er ikke en anbefalet praksis, da der ikke er nogen garanti for, at programmet er i stand til at gøre noget pålideligt, efter at fejlen blev kastet.

Q7. Hvilken undtagelse vil blive kastet ved udførelse af følgende kodeblokering?

Heltal [] [] ints = {{1, 2, 3}, {null}, {7, 8, 9}}; System.out.println ("værdi =" + ints [1] [1] .intValue ());

Det kaster en ArrayIndexOutOfBoundsException da vi forsøger at få adgang til en position, der er større end længden af ​​arrayet.

Q8. Hvad er undtagelseskædning?

Opstår, når en undtagelse smides som svar på en anden undtagelse. Dette giver os mulighed for at opdage den komplette historie om vores rejste problem:

prøv {task.readConfigFile (); } catch (FileNotFoundException ex) {throw new TaskException ("Kunne ikke udføre opgave", ex); }

Q9. Hvad er et stacktrace, og hvordan relaterer det sig til en undtagelse?

Et stakspor giver navnene på de klasser og metoder, der blev kaldt, fra starten af ​​applikationen til det punkt, hvor der opstod en undtagelse.

Det er et meget nyttigt fejlfindingsværktøj, da det giver os mulighed for at bestemme nøjagtigt, hvor undtagelsen blev kastet i applikationen og de originale årsager, der førte til den.

Q10. Hvorfor ønsker du at underklasse en undtagelse?

Hvis undtagelsestypen ikke er repræsenteret af dem, der allerede findes på Java-platformen, eller hvis du har brug for at give mere information til klientkoden for at behandle den på en mere præcis måde, skal du oprette en brugerdefineret undtagelse.

Beslutningen om, hvorvidt en brugerdefineret undtagelse skal kontrolleres eller fjernes, afhænger helt af forretningssagen. Dog som en tommelfingerregel; Hvis koden ved hjælp af din undtagelse kan forventes at komme sig fra den, skal du oprette en afkrydset undtagelse, ellers gør den ukontrolleret.

Du skal også arve fra det mest specifikke Undtagelse underklasse, der er tæt knyttet til den, du vil kaste. Hvis der ikke er en sådan klasse, skal du vælge Undtagelse som forælder.

Q11. Hvad er nogle fordele ved undtagelser?

Traditionelle teknikker til påvisning og håndtering af fejl fører ofte til spaghetti-kode, der er svær at vedligeholde og vanskelig at læse. Undtagelser gør det dog muligt for os at adskille kernelogikken i vores applikation fra detaljerne i, hvad vi skal gøre, når der sker noget uventet.

Da JVM også søger baglæns gennem opkaldsstakken for at finde eventuelle metoder, der er interesserede i at håndtere en bestemt undtagelse; vi får muligheden for at udbrede en fejl op i opkaldstakken uden at skrive yderligere kode.

Da alle undtagelser, der kastes i et program, er objekter, kan de også grupperes eller kategoriseres ud fra dets klassehierarki. Dette giver os mulighed for at fange en gruppe undtagelser i en enkelt undtagelsesbehandler ved at specificere undtagelsens superklasse i fangst blok.

Q12. Kan du smide en undtagelse inde i et Lambda-udtryks krop?

Når du bruger en standard funktionel grænseflade, der allerede er leveret af Java, kan du kun kaste ukontrollerede undtagelser, fordi standard funktionelle grænseflader ikke har en "kaster" -klausul i metodesignaturer:

Liste heltal = Arrays.asList (3, 9, 7, 0, 10, 20); heltal.forEach (i -> {if (i == 0) {kast nyt IllegalArgumentException ("Nul ikke tilladt");} System.out.println (Math.PI / i);});

Men hvis du bruger en brugerdefineret funktionel grænseflade, er det muligt at kaste afkrydsede undtagelser:

@FunctionalInterface offentlig statisk grænseflade CheckedFunction {ugyldig anvendelse (T t) kaster Undtagelse; }
public void processTasks (List taks, CheckedFunction checkedFunction) {for (Task task: taks) {try {checkedFunction.apply (task); } fange (Undtagelse e) {// ...}}} processTasks (taskList, t -> {// ... throw new Exception ("Der skete noget");});

Q13. Hvilke regler skal vi følge, når vi tilsidesætter en metode, der giver en undtagelse?

Flere regler dikterer, hvordan undtagelser skal erklæres i forbindelse med arv.

Når overordnet klassemetode ikke kaster nogen undtagelser, kan underordnet klassemetode ikke kaste nogen afkrydset undtagelse, men det kan muligvis kaste alle umarkerede.

Her er en eksempelkode for at demonstrere dette:

class Parent {void doSomething () {// ...}} class Child extends Parent {void doSomething () throw IllegalArgumentException {// ...}}

Det næste eksempel kan ikke kompileres, da den overordnede metode kaster en markeret undtagelse, der ikke er angivet i den tilsidesatte metode:

class Parent {void doSomething () {// ...}} class Child extends Parent {void doSomething () throw IOException {// Compilation error}}

Når overordnet klassemetode kaster en eller flere afkrydsede undtagelser, kan underordnet klassemetode kaste enhver ukontrolleret undtagelse. alle, ingen eller en delmængde af de erklærede afkrydsede undtagelser, og endda et større antal af disse, så længe de har samme omfang eller snævrere.

Her er et eksempel på en kode, der med succes følger den tidligere regel:

klasse Forælder {void doSomething () kaster IOException, ParseException {// ...} ugyldig doSomethingElse () kaster IOException {// ...}} klasse Child udvider Parent {void doSomething () kaster IOException {// ...} ugyldigt doSomethingElse () kaster FileNotFoundException, EOFException {// ...}}

Bemærk, at begge metoder overholder reglen. Den første kaster færre undtagelser end den tilsidesatte metode, og den anden, selvom den kaster mere; de er smallere.

Men hvis vi forsøger at smide en afkrydset undtagelse, som den overordnede klassemetode ikke erklærer, eller vi kaster en med et bredere omfang; vi får en kompileringsfejl:

klasse Forælder {void doSomething () kaster FileNotFoundException {// ...}} klasse Child udvider Forælder {void doSomething () kaster IOException {// Kompileringsfejl}}

Når den overordnede klassemetode har en kasteklausul med en ikke-markeret undtagelse, kan metoden til underordnet klasse ikke kaste nogen eller et hvilket som helst antal ikke-markerede undtagelser, selvom de ikke er relaterede.

Her er et eksempel, der respekterer reglen:

class Parent {void doSomething () throw IllegalArgumentException {// ...}} class Child extends Parent {void doSomething () throw ArithmeticException, BufferOverflowException {// ...}}

Q14. Vil den følgende kode kompilere?

ugyldig doSomething () {// ... smid ny RuntimeException (ny undtagelse ("Lænket undtagelse")); }

Ja. Ved kædning af undtagelser er compileren kun opmærksom på den første i kæden, og fordi den registrerer en ukontrolleret undtagelse, behøver vi ikke tilføje en kaste-klausul.

Q15. Er der nogen måde at kaste en kontrolleret undtagelse fra en metode, der ikke har en kasteklausul?

Ja. Vi kan drage fordel af typen sletning udført af kompilatoren og få den til at tro, at vi kaster en ukontrolleret undtagelse, når det faktisk er; vi kaster en kontrolleret undtagelse:

offentlig T sneakyTrow (Throwable ex) kaster T {throw (T) ex; } public void methodWithoutThrows () {this.sneakyThrow (ny undtagelse ("Kontrolleret undtagelse")); }

3. Konklusion

I denne artikel har vi undersøgt nogle af de spørgsmål, der sandsynligvis vises i tekniske interviews for Java-udviklere, vedrørende undtagelser. Dette er ikke en udtømmende liste, og den bør kun behandles som starten på yderligere forskning.

Vi i Baeldung ønsker dig succes i alle kommende interviews.

Næste » Java Annotations Interview Spørgsmål (+ svar) « Tidligere interviewspørgsmål med Java Flow Control (+ svar)

$config[zx-auto] not found$config[zx-overlay] not found