Java kivételek interjúkérdések (+ válaszok)

Ez a cikk egy sorozat része: • Java Collections interjúkérdések

• Java típusú rendszerinterjúkérdések

• Java egyidejű interjúkérdések (+ válaszok)

• Java osztály felépítése és inicializálása interjúkérdések

• Java 8 interjúkérdések (+ válaszok)

• Memóriakezelés Java interjúkérdésekben (+ válaszok)

• Java Generics interjúkérdések (+ válaszok)

• Java Flow Control interjúkérdések (+ válaszok)

• Java kivételek interjúkérdések (+ válaszok) (aktuális cikk) • Java kommentárok interjúkérdések (+ válaszok)

• A tavaszi keretrendszer legfontosabb interjúi

1. Áttekintés

A kivételek elengedhetetlen téma, amelyet minden Java fejlesztőnek ismernie kell. Ez a cikk néhány kérdésre ad választ, amelyek egy interjú során felmerülhetnek.

2. Kérdések

Q1. Mi a kivétel?

Kivételt képez egy olyan rendellenes esemény, amely egy program végrehajtása során következik be, és megzavarja a program utasításainak normál folyamatát.

Q2. Mi a dobás és dobás kulcsszavak célja?

A dob kulcsszóval adható meg, hogy egy metódus kivételt okozhat a végrehajtása során. Kifejezett kivételkezelést hajt végre metódus meghívásakor:

public void simpleMethod () kiveti a kivételt {// ...}

A dobás kulcsszó lehetővé teszi számunkra, hogy egy kivétel objektumot dobjunk a program normál folyamatának megszakításához. Ezt leggyakrabban akkor használják, ha egy program nem felel meg egy adott feltételnek:

if (task.isTooComplicated ()) {dobjon új TooComplicatedException-t ("A feladat túl bonyolult"); }

Q3. Hogyan tud kezelni egy kivételt?

Az a használatával próbáld meg utolérni nyilatkozat:

próbáld meg a {// ...} catch (ExceptionType1 ex) {// ...} catch (ExceptionType2 ex) {// ...} végül {// ...}

Az a kódblokk, amelyben kivétel fordulhat elő, a próbáld ki Blokk. Ezt a blokkot „védett” vagy „őrzött” kódnak is nevezik.

Kivétel esetén a fogás a dobott kivételnek megfelelő blokk végrehajtásra kerül, ha nem, akkor mindet fogás a blokkokat figyelmen kívül hagyják.

A végül blokk mindig a próbáld ki blokk kijáratok, függetlenül attól, hogy kivételt dobtak-e vagy sem.

Q4. Hogyan foghat meg több kivételt?

Háromféle módon kezelhető több kivétel egy kódblokkban.

Az első a fogás blokk, amely képes kezelni az összes dobott kivételtípust:

próbáld meg a {// ...} catch (ex Kivétel ex) {// ...}

Ne feledje, hogy az ajánlott gyakorlat a lehető legpontosabb kivételkezelők használata.

A túl tág kivételkezelők a kódot hibára hajlamosabbá tehetik, olyan kivételeket foghatnak el, amelyekre nem számítottak, és váratlan viselkedést okozhatnak a programban.

A második módszer több elkapási blokk megvalósítása:

próbáld meg a {// ...} catch (FileNotFoundException ex) {// ...} catch (EOFException ex) {// ...}

Vegye figyelembe, hogy ha a kivételeknek öröklődési viszonyuk van; a gyermektípusnak kell elsőnek lennie, a szülőnek pedig később. Ha ezt nem sikerül megtenni, az fordítási hibát eredményez.

A harmadik egy multi-catch blokk használata:

próbáld meg a {// ...} catch (FileNotFoundException | EOFException ex) {// ...}

Ez a funkció először a Java 7-ben került bevezetésre; csökkenti a kódduplikációt és megkönnyíti a karbantartást.

Q5. Mi a különbség az ellenőrzött és az ellenőrizetlen kivétel között?

Az ellenőrzött kivételt az a-n belül kell kezelni próbáld elkapni blokkolja vagy deklarálja a dob kikötés; mivel nem ellenőrzött kivételt nem kell kezelni és deklarálni sem.

Az ellenőrzött és nem ellenőrzött kivételeket fordítási és futásidejű kivételnek is nevezik.

Minden kivétel be van jelölve, kivéve a Hiba, RuntimeException, és azok alosztályai.

Q6. Mi a különbség a kivétel és a hiba között?

Kivételt képez egy olyan esemény, amely olyan állapotot képvisel, amelyből helyre lehet állni, míg a hiba egy külső helyzetet jelent, amelyből általában lehetetlen helyreállni.

A JVM által dobott összes hiba a Hiba vagy annak egyik alosztálya, a leggyakoribbak a következőket tartalmazzák, de nem kizárólagosan:

  • OutOfMemoryError - dobott, amikor a JVM nem tud több objektumot lefoglalni, mert nincs memóriája, és a szemétszedő nem tudta elérhetőbbé tenni
  • StackOverflowError - akkor fordul elő, amikor egy szál veremterülete elfogy, általában azért, mert egy alkalmazás túl mélyen visszatér
  • ExceptionInInitializerError - jelzi, hogy váratlan kivétel történt a statikus inicializáló kiértékelése során
  • NoClassDefFoundError - akkor dobódik, amikor az classloader megpróbálja betölteni az osztály definícióját, és nem találta meg, általában azért, mert a szükséges osztály fájlokat nem találtunk az osztályúton
  • UnsupportedClassVersionError - akkor fordul elő, amikor a JVM megpróbálja elolvasni a osztály fájlt, és megállapítja, hogy a fájlban szereplő verzió nem támogatott, általában azért, mert a fájlt a Java újabb verziójával hozták létre

Bár egy hiba kezelhető a próbáld ki állítás, ez nem ajánlott gyakorlat, mivel nincs garancia arra, hogy a program bármit megbízhatóan meg tud majd tenni a hiba elvetése után.

Q7. Milyen kivételt dob ​​a következő kódblokk végrehajtása?

Egész szám [] [] ints = {{1, 2, 3}, {null}, {7, 8, 9}}; System.out.println ("value =" + ints [1] [1] .intValue ());

Dob egy ArrayIndexOutOfBoundsException mivel a tömb hosszánál nagyobb pozícióhoz próbálunk hozzáférni.

Q8. Mi a kivétel láncolás?

Akkor fordul elő, ha egy kivétel egy másik kivételre reagál. Ez lehetővé teszi számunkra, hogy felfedezzük felvetett problémánk teljes történetét:

próbáld ki a {task.readConfigFile () parancsot; } catch (FileNotFoundException ex) {dobjon új TaskException-t ("Nem sikerült végrehajtani a feladatot", ex); }

Q9. Mi a Stacktrace és hogyan viszonyul a kivételhez?

A veremkövetés megadja a meghívott osztályok és módszerek nevét, az alkalmazás kezdetétől a kivételig.

Ez egy nagyon hasznos hibakereső eszköz, mivel lehetővé teszi számunkra, hogy pontosan meghatározzuk, hová dobták a kivételt az alkalmazásban, és az eredeti okokat, amelyek ahhoz vezettek.

Q10. Miért szeretne alosztályt adni egy kivételnek?

Ha a kivétel típusát nem a Java platformon már létező típusok képviselik, vagy ha több információt kell megadnia az ügyfélkódnak a pontosabb kezelés érdekében, akkor létre kell hoznia egy egyedi kivételt.

Annak eldöntése, hogy ellenőrizni kell-e az egyedi kivételt, vagy sem, teljesen az üzleti esettől függ. Alapszabályként azonban; ha a kivételedet használó kód várhatóan helyreáll belőle, akkor hozzon létre egy bejelölt kivételt, különben tegye ellenőrizhetetlenné.

Örökölnie kell a legspecifikusabbaktól is Kivétel alosztály, amely szorosan kapcsolódik ahhoz, amelyet dobni szeretne. Ha nincs ilyen osztály, akkor válassza Kivétel mint szülő.

Q11. Melyek a kivételek előnyei?

A hagyományos hibadetektálási és -kezelési technikák gyakran vezetnek spagettikódhoz, amelyet nehéz fenntartani és nehezen olvasható. A kivételek azonban lehetővé teszik számunkra, hogy elválasszuk alkalmazásunk alapvető logikáját a részletekről, hogy mit tegyünk, ha váratlan esemény történik.

Továbbá, mivel a JVM visszafelé keres a hívásveremben, hogy megtalálja az adott kivétel kezelésében érdekelt módszereket; lehetőséget kapunk arra, hogy egy hibát tovább terjesszünk a hívásveremben anélkül, hogy további kódot írnánk.

Továbbá, mivel a programba dobott összes kivétel objektum, csoportosíthatók vagy kategorizálhatók az osztály hierarchiája alapján. Ez lehetővé teszi számunkra, hogy egyetlen kivételkezelőben csoportosítsuk a kivételek egy csoportját, megadva a kivétel szuperosztályát a fogás Blokk.

Q12. Dobhat-e bármilyen kivételt a lambda kifejezés testébe?

A Java által már biztosított szabványos funkcionális felület használatakor csak ellenőrizetlen kivételeket dobhat, mivel a szokásos funkcionális interfészek nem tartalmaznak „dobási” záradékot a metódus aláírásokban:

Egész számok = tömbök. AsList (3, 9, 7, 0, 10, 20); integers.forEach (i -> {if (i == 0) {dobjon új IllegalArgumentException-t ("Nulla nem engedélyezett");} System.out.println (Math.PI / i);});

Ha azonban egyedi funkcionális felületet használ, akkor be lehet vetni az ellenőrzött kivételeket:

@FunctionalInterface nyilvános statikus felület CheckedFunction {void Apply (T t) dobja a Kivételt; }
public void processTasks (Taks lista, CheckedFunction ellenőrzött funkció) {for (Feladatfeladat: taks) {try {ellenőrzöttFunction.apply (feladat); } catch (e kivétel) {// ...}}} processTasks (taskList, t -> {// ... dobjon új kivételet ("Valami történt");});

Q13. Milyen szabályokat kell betartanunk, ha felülírunk egy kivételt eldöntő módszert?

Több szabály meghatározza, hogy a kivételeket hogyan kell deklarálni az öröklés összefüggésében.

Ha a szülő osztály metódusa nem vet ki kivételt, a gyermek osztály metódus nem dobhat be semmilyen bejelölt kivételt, de ellenőrizetlenül dobhat.

Íme egy példa kód ennek bemutatására:

osztály Szülő {void doSomething () {// ...}} osztály Gyermek kiterjeszti Szülő {void doSomething () dobja az IllegalArgumentException {// ...}}

A következő példa nem fog összeállítani, mivel az felülbíráló módszer egy ellenőrzött kivételt dob, amelyet nem deklaráltak az felülbírált módszerben:

osztály Szülő {void doSomething () {// ...}} osztály Gyermek kiterjeszti Szülő {void doSomething () dobja IOException {// fordítási hiba}}

Amikor a szülő osztály módszere egy vagy több bejelölt kivételt dob, a gyermek osztály módszer bármilyen ellenőrizetlen kivételt felvethet; az összes, egyik sem vagy egy része a deklarált ellenőrzött kivételeknek, sőt ezek nagyobb száma is, amennyiben azonos vagy szűkebb körűek.

Íme egy példa kód, amely sikeresen követi az előző szabályt:

osztály Szülő {void doSomething () dobja IOException, ParseException {// ...} void doSomethingElse () dobja IOException {// ...}} class Child meghosszabbítja Szülő {void doSomething () dobja IOException {// ...} void doSomethingElse () dobja a FileNotFoundException, EOFException {// ...}}

Vegye figyelembe, hogy mindkét módszer betartja a szabályt. Az első kevesebb kivételt dob, mint az felülbírált módszer, a második pedig annak ellenére, hogy többet dob; szűkebb körűek.

Ha azonban megpróbálunk bejelölni egy bejelölt kivételt, amelyet a szülő osztály metódusa nem deklarál, vagy tágabb hatókörrel dobunk egyet; összeállítási hibát kapunk:

osztály Szülő {void doSomething () dobja a FileNotFoundException {// ...}} osztály Gyermek kiterjeszti Szülő {void doSomething () dobja IOException {// fordítási hiba}}

Ha a szülő osztály metódusában van dobási záradék, ellenőrizetlen kivétellel, akkor a gyermek osztály metódus egy vagy több tetszőleges számú ellenőrizetlen kivételt dobhat, annak ellenére, hogy nem kapcsolódnak egymáshoz.

Íme egy példa, amely tiszteletben tartja a szabályt:

class Szülő {void doSomething () dobja az IllegalArgumentException {// ...}} osztályt a gyermek kiterjeszti a Szülő {void doSomething () dobja ArithmeticException, BufferOverflowException {// ...}}

Q14. Összeállítja a következő kódot?

void doSomething () {// ... dobja az új RuntimeException-t (új kivétel ("Láncolt kivétel")); }

Igen. Kivételek láncolásakor a fordító csak a lánc elsőjével törődik, és mivel ellenőrizetlen kivételt észlel, nem kell hozzáadnunk egy dobási záradékot.

Q15. Van-e valamilyen módja annak, hogy ellenőriztett kivételt dobjunk egy olyan módszer alól, amely nem rendelkezik dobási záradékkal?

Igen. Kihasználhatjuk a fordító által végrehajtott típusú törlést, és azt gondolhatjuk róla, hogy ellenőrizetlen kivételt vetünk be, bár valójában; ellenőrzött kivételt dobunk:

nyilvános T sneakyThrow (Throwable ex) dob T {dobás (T) ex; } public void methodWithoutThrows () {this.sneakyThrow (új kivétel ("Ellenőrzött kivétel")); }

3. Következtetés

Ebben a cikkben megvizsgáltunk néhány olyan kérdést, amely valószínűleg a Java-fejlesztők számára készített technikai interjúkban jelenik meg, a kivételekkel kapcsolatban. Ez nem teljes körű felsorolás, és csak a további kutatások kezdeteként kell kezelni.

Mi, a Baeldungnál sikert kívánunk a közelgő interjúkhoz.

Következő » Java kommentárok Interjúkérdések (+ válaszok) « Korábbi Java Flow Control interjúkérdések (+ válaszok)

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