Típusok

Az exception hierarchia megértése segít eldönteni, mit kell kezelni, mit lehet továbbdobni, és mi számít rendszerhibának.

1. Definíció

A Java exception modellje osztályhierarchiára épül: Throwable alatt található az Error és az Exception, utóbbin belül pedig a checked és unchecked ág. Interjún ennek megértése alap, mert ebből következik a fordító viselkedése és a hibakezelési stratégia. A téma a nyelvi szintaxis és a rendszertervezés határán van. Nem elég felsorolni a kategóriákat; tudni kell, hogy egy adott hibatípusnál mit vársz el a hívótól.

2. Alapfogalmak

Fogalom	Jelentés	Miért fontos
Throwable	A teljes hibahierarchia gyökere	Közvetlenül ritkán használjuk üzleti kódban.
Error	Súlyos rendszer- vagy JVM-szintű hiba	Tipikusan nem kezeljük alkalmazáslogikával.
Checked exception	Fordító által kikényszerített kivétel	A hívónak kezelnie vagy deklarálnia kell.
Unchecked exception	RuntimeException és leszármazottai	Jellemzően programozási hiba vagy szerződésszegés.
Exception hierarchy	A hibák kategorizálásának szerkezete	Segíti a megfelelő absztrakciós szintű kezelést.

• A checked exception-eket a fordító számonkéri, ezért alkalmasak várható, helyreállítható problémák jelzésére, például I/O hibákra.
• Az unchecked exception tipikusan programozási vagy validációs hiba: NullPointerException, IllegalArgumentException, IllegalStateException.
• Az Error kategória általában nem üzleti logika célpontja; ide tartozik például OutOfMemoryError.
• Interjún fontos megkülönböztetni: nem minden futásidejű hiba unchecked exception, mert az Error külön ág.

3. Gyakorlati használat

A(z) Típusok témában a legfontosabb gyakorlati kérdés mindig az, hogy milyen use-case-re választasz eszközt. A jó interjúválasz itt nem csak azt mondja meg, mit lehet csinálni, hanem azt is, mikor érdemes és mikor nem.

• Használj checked exception-t, ha a hívó reálisan tud dönteni a helyreállításról vagy alternatív ágról.
• Használj unchecked exception-t, ha a hívó helytelenül használta az API-t, vagy invariáns sérült.
• Ne kapj el vakon Throwable-t vagy Exception-t csak azért, hogy “ne dőljön el” a program; ez elrejtheti a valódi hibát.
• Interjún jó pont, ha kiemeled, hogy a keretrendszerek sokszor unchecked irányba tolják a fejlesztőket az egyszerűbb API miatt.

4. Kód példák

Egyszerű példa

import java.io.IOException;

public class CheckedExample {
    public void read() throws IOException {
        throw new IOException("Disk error");
    }
}

Haladó példa

public class UncheckedVsError {
    public static void validateAge(int age) {
        if (age < 0) {
            throw new IllegalArgumentException("age must be positive");
        }
    }

    public static void main(String[] args) {
        validateAge(-1); // unchecked exception
        // new OutOfMemoryError() rendszerhibát jelezne, nem üzleti validációt
    }
}

A kódpéldák interjún azért hasznosak, mert megmutatják, hogy a fogalmi szintű tudást le tudod fordítani konkrét API-használatra. Ha röviden el tudod magyarázni, miért így írod a példát, az általában többet ér, mint egy túlbonyolított demo.

5. Trade-offok

Szempont	Előny	Hátrány
Checked exception	Kikényszeríti a tudatos kezelést	Szennyezheti a szignatúrákat és a réteghatárokat
Unchecked exception	Egyszerűbb API és kevesebb boilerplate	Könnyebb figyelmen kívül hagyni a hibautakat
Széles catch blokk	Gyors hibafogás prototípusnál	Könnyen elrejti a valódi kategóriát

6. Gyakori hibák

• ❌ Rossz: Minden hibát checked exceptionként modellezel. ✅ Helyes: Csak a helyreállítható, várható hibákhoz használj checked exception-t.
• ❌ Rossz: Error-t is ugyanúgy kezeled, mint egy üzleti kivételt. ✅ Helyes: Az Error általában nem normál üzleti recoverable helyzet.
• ❌ Rossz: RuntimeException-t dobálsz minden dokumentáció nélkül. ✅ Helyes: Az unchecked kivételnek is legyen világos jelentése és üzenete.

7. Senior szintű meglátások

Senior szinten a kérdés nem az, hogy checked vagy unchecked “jobb”, hanem hogy melyik illik az adott architektúrához. Egy publikus library más döntést hozhat, mint egy belső mikroszerviz.

Follow-up kérdés: miért használ sok modern framework inkább unchecked kivételeket? Mert csökkentik a rétegek közti zajt, és gyakran központi exception handlinggel dolgoznak.

Az exception hierarchia jó tervezési eszköz is: megmutatja, hol vársz recoverable problémát, és hol tekinted hibás használatnak a helyzetet.

Tipikus follow-up interjúkérdések:

• Hogyan magyaráznád el röviden a(z) Típusok témát egy junior fejlesztőnek?
• Milyen trade-offot látsz a(z) Típusok kapcsán valós projektben?
• Milyen tipikus production hibát tudsz ehhez a témához kötni?

8. Szószedet

Kifejezés	Jelentés
checked exception	Fordító által kikényszerített kivétel.
unchecked exception	RuntimeException alapú kivétel, amit nem kötelező deklarálni.
error	Súlyos JVM- vagy rendszerhiba.
throws clause	A metódus szignatúrájában deklarált dobható kivétel.
recovery	Helyreállítás vagy alternatív végrehajtási út.

9. Gyorsreferencia

• Throwable → Error + Exception.
• Checked = kezelni/deklarálni kell.
• Unchecked = RuntimeException ág.
• Error-t jellemzően nem business logic kezeli.
• Választáskor a recoverability a kulcskérdés.

Ha interjún elakadsz, a(z) Típusok témánál mindig térj vissza a három alapelvhez: pontos definíció, tipikus use-case, és a legfontosabb trade-off vagy hiba.