Típusok

A jó exception kezelés első lépése annak felismerése, hogy pontosan milyen hibával állunk szemben: kezelhető helyzet, hívói hiba, infrastruktúra-probléma vagy JVM-szintű összeomlás.

1. Definíció

Mi az exception típus?

A Java-ban az exception típusok olyan rendellenes helyzeteket írnak le, amelyek megszakítják a program normál vezérlési folyamatát.

Ezeket a Throwable hierarchia osztályai reprezentálják.

Ez a hierarchia nem pusztán egy taxonómia.

Fontos tervezési jelzéseket hordoz arról, hogy:

• a hívó várhatóan tud-e helyreállni
• a fordító kikényszeríti-e a kezelést
• a hiba inkább üzleti helyzet, programozói hiba vagy rendszerösszeomlás

Miért fontos a típus?

A konkrét exception típus hatással van:

• a metódus szignatúrájára
• az API használhatóságára
• a logolási stratégiára
• a retry viselkedésre
• a tranzakciókezelésre
• a monitorozásra és riasztásra
• az interjúválasz minőségére

Ha rossz exception típust választasz, a kód még lefordulhat, de az API félrevezető lesz.

Ezért a senior fejlesztők az exception típust a publikus szerződés részének tekintik, nem csak hibacímkének.

A hierarchia gyökere

Minden eldobható objektum a Throwable-ből származik.

A két fő ág:

• Error
• Exception

Az Exception ágon belül a legfontosabb különbség:

• checked exception
• unchecked exception (RuntimeException és leszármazottai)

Ez a felosztás a Java exception kezelés legtöbb beszélgetésének a magja.

2. Alapfogalmak

2.1 `Throwable`

2.1.1 Kulcsszavak és szerződések, amelyeket itt explicit módon ki kell mondani

Ez a téma akkor lesz igazán tiszta, ha néven nevezzük a hierarchia és a szerződés kulcsszavait:

• Throwable — minden eldobható dolog közös gyökértípusa.
• Error — JVM- vagy környezetszintű hibakategória, amelyből az alkalmazáskód normál üzemi folyamatként általában nem áll helyre.
• Exception — az alkalmazás felől értelmezett kivételes helyzetek ága.
• checked exception — olyan kivétel, amelyet a compiler elkapásra vagy deklarálásra kényszerít.
• unchecked exception — RuntimeException-alapú hiba, amelyet a metódusszignatúra nem kényszerít ki.
• cause — az eredeti technikai gyökérok, amelyet a magasabb szintű kivételhez kapcsolsz.
• stack trace — a hiba pillanatában rögzített végrehajtási útvonal.
• suppressed exception — másodlagos hiba, gyakran cleanup közben, amely egy elsődleges kivételhez csatolódik.

Ezek nem csak címkék: a helyreállítási elvárást, az API-terhelést és a hiba szemantikáját kommunikálják.

A Throwable minden eldobható érték közös ősosztálya.

Tárolja:

• az üzenetet
• a stack trace-t
• a cause-t
• a suppressed exceptionöket

A gyakorlatban ritkán tervezel közvetlenül Throwable szinten.

Jellemzően specifikusabb absztrakcióval dolgozol.

2.2 `Error`

Az Error olyan súlyos problémákat jelöl, amelyeket az alkalmazás általában nem üzleti folyamatként kezel.

Tipikus példák:

• OutOfMemoryError
• StackOverflowError
• NoClassDefFoundError

Ezek többnyire ezt jelzik:

• JVM vagy erőforrás probléma
• deployment vagy konfigurációs hiba
• sérült runtime feltételezés

Interjún gyakori pont, hogy az Error része a hierarchiának, de általában nem kezeljük normál alkalmazáslogikaként.

2.3 Checked exceptionök

A checked exceptionöket a fordító arra kényszeríti, hogy vagy:

• elkapd őket
• vagy deklaráld throws-zal

Példák:

• IOException
• régebbi API-knál SQLException
• ClassNotFoundException

A checked exception azt jelzi, hogy a hívónak tudatos döntést kell hoznia.

Ez a döntés lehet:

• helyreállítás
• fordítás más absztrakcióra
• továbbdobás plusz kontextussal

A tervezési szándék az explicitsség.

2.4 Unchecked exceptionök

Az unchecked exceptionök a RuntimeException leszármazottai.

Példák:

• IllegalArgumentException
• IllegalStateException
• NullPointerException
• IndexOutOfBoundsException

Ezek jellemzően ezt jelzik:

• programozói hiba
• megsértett előfeltétel
• hibás állapotátmenet
• API helytelen használata

Nem kötelezőek a metódus szignatúrájában.

Ez egyszerűbb API-t eredményez, de nagyobb felelősséget tesz a fejlesztőre a jó dokumentálásban.

2.5 Helyreállítás versus hibajelzés

Az egyik legerősebb gyakorlati heurisztika a következő:

• checked exceptiont akkor használj, ha a hívó ésszerűen helyre tud állni
• unchecked exceptiont akkor használj, ha a hiba inkább bug vagy szerződésszegés

Ez nem tökéletes szabály, de sokkal jobb, mint elszigetelt példákat bemagolni.

2.6 Exception hierarchia mint API kommunikáció

Az exception típus kommunikáció.

Például:

• az IllegalArgumentException azt mondja, hogy a hívó rossz értéket adott
• az IllegalStateException azt mondja, hogy az objektum rossz állapotban van
• az UnsupportedOperationException azt mondja, hogy a művelet szándékosan nem támogatott
• az IOException azt mondja, hogy egy külső I/O határon hiba történt

A jó típusválasztás javítja az olvashatóságot és a hibadiagnosztikát.

2.7 Cause láncok

Egy jó exception modell megőrzi az eredeti cause-t.

throw new IllegalStateException("Failed to load user profile", ioException);

Cause lánc nélkül a hibakeresés sokkal nehezebb.

A típus azt mondja meg, mi történt az aktuális absztrakciós szinten.

A cause azt mutatja meg, honnan indult a probléma.

3. Gyakorlati használat

Domain probléma versus infrastruktúra-probléma

Tegyük fel, hogy egy fizetés meghiúsul.

Az exception stratégiának különbséget kell tennie a következők között:

• hibás kliens input
• üzleti elutasítás, például elégtelen fedezet
• hálózati timeout egy külső szolgáltató felé
• belső programozói hiba

Ezek nem felcserélhető kategóriák.

Más kezelést és más megfigyelhetőséget igényelnek.

A checked exceptionök tipikus helye

A checked exceptionök akkor működnek jól, ha:

• a hiba külső eredetű
• a hívó retry-t vagy fallbacket alkalmazhat
• a hiba normál működés közben is előfordulhat
• a metódushatár inkább alacsony szintű vagy infrastruktúra-jellegű

Példák: fájlkezelés, reflection lookup, egyes legacy API-k.

Az unchecked exceptionök tipikus helye

Az unchecked exceptionök akkor illenek, ha:

• egy előfeltétel sérül
• egy objektumot rosszul használnak
• valószínűleg bug van
• a throws kötelező terjesztése csak zajt okozna

Ezért választ sok modern framework unchecked exceptiont programozói hibák jelzésére.

Gyakori tervezési kérdés

Minden üzleti hibát checked exceptionként kell modellezni?

Nem feltétlenül.

Sok csapat az elvárt üzleti kimeneteleket inkább így modellezi:

• visszatérési típusokkal
• result objektumokkal
• validációs objektumokkal
• határfelületeken domain-specifikus unchecked exceptionökkel

A helyes választás attól függ, mennyire valóban kivételes az adott helyzet.

Logolás és riasztás

Az exception típus az operatív kezelést is befolyásolja.

Például:

• a publikus API-ból jövő IllegalArgumentException hibás kliens inputot jelezhet
• az IllegalStateException belső bugra utalhat
• az ismétlődő IOException infrastruktúra-instabilitást jelezhet
• az OutOfMemoryError általában azonnali operatív vizsgálatot igényel

Itt válik az exception taxonómia valódi production engineering kérdéssé.

4. Kód példák

1. példa — Checked exception

import java.io.IOException;

public class FileReaderService {
    public String readConfig() throws IOException {
        throw new IOException("Config file not found");
    }
}

A hívónak explicit módon döntenie kell a kezelésről.

2. példa — Unchecked exception hibás argumentumra

public class AgeValidator {
    public void validate(int age) {
        if (age < 0) {
            throw new IllegalArgumentException("age must be non-negative");
        }
    }
}

Ez hívói szerződésszegést kommunikál.

3. példa — Hibás állapot

public class ReportExporter {
    private boolean initialized;

    public void initialize() {
        initialized = true;
    }

    public void export() {
        if (!initialized) {
            throw new IllegalStateException("Exporter must be initialized first");
        }
    }
}

Ez nem rossz inputot, hanem hibás objektuméletciklus-használatot jelez.

4. példa — Cause megőrzése

import java.io.IOException;

public class ProfileService {
    public void loadProfile() {
        try {
            throw new IOException("Disk read failed");
        } catch (IOException exception) {
            throw new IllegalStateException("Could not load profile", exception);
        }
    }
}

Az absztrakció megváltozik, de az eredeti ok megmarad.

5. példa — Az `Error` más kategória

public class ErrorExample {
    public static void main(String[] args) {
        throw new StackOverflowError("Demonstration only");
    }
}

Ez nem normál üzleti hibamodellezés.

5. Trade-offok

A tervezési feszültség mindig ugyanaz.

Erősebb explicitsséget akarsz, vagy kisebb API felületet?

A jó design a hívói felelősség alapján dönt, nem megszokásból.

6. Gyakori hibák

1. Mindenre `Exception` dobása

Ez elpusztítja a szándékot.

A kód lefordul, de az API már nem kommunikálja, mi történt valójában.

2. Checked exception használata programozói hibákra

Például a hibás metódusargumentumot általában jobb unchecked exceptionnel, például IllegalArgumentExceptionnel jelezni.

3. Cause elnyelése

Ha lecseréled az exception típust, de nem őrzöd meg a cause-t, a diagnosztika sokkal nehezebb lesz.

4. `Throwable` elkapása

Ez szinte mindig túl tág.

Az Error ág elemeit is elkapja, ami normál alkalmazáslogikában általában nem cél.

5. `Error` kezelése üzleti folyamatként

Az OutOfMemoryError nem validációs eredmény.

Ez rendszerhibát jelez.

6. Inkonzisztens típushasználat

Ha a kód egyik része IllegalArgumentException-t, egy másik ugyanarra a hívói hibára IllegalStateException-t dob, az API zavarossá válik.

7. Mélymerülés

Miért maradtak meg a checked exceptionök?

A checked exceptionök megosztóak.

Sokan szeretik az explicitsséget.

Sokan a boilerplate miatt utálják.

Mégis egy fontos tervezési gondolatot fejeznek ki:

vannak hibák, amelyek megérdemlik a hívó első osztályú figyelmét.

Akár sokat, akár keveset használod őket, a mögöttük lévő szándékot érteni kell.

Exception típusok és architektúra

Alacsonyabb rétegekben az infrastruktúra-specifikus checked exceptionök teljesen indokoltak lehetnek.

Magasabb rétegekben ezeket az alkalmazás gyakran lefordítja:

• domain exceptionökre
• service-layer exceptionökre
• HTTP válaszokra
• error result objektumokra

Ezért az exception típusok az architekturális határfelületek részei.

Interjús keretezés

Egy erős interjúválasz nem áll meg ott, hogy „a checked exceptiont deklarálni kell”.

Jellemzően hozzáteszi:

• milyen hibát reprezentál a típus
• tud-e a hívó helyreállni
• az exception típus az API kommunikáció része-e
• hogyan hat a választás a diagnosztikára és a tervezésre

Ez a plusz réteg teszi a választ senior szintűvé.

Pontosság a dogmák helyett

Nincs tökéletes univerzális szabály, például hogy a checked mindig jobb vagy az unchecked mindig modernebb.

A jobb szabály inkább ez:

azt a típust válaszd, amelyik a legjobban kommunikálja a felelősséget és a várható kezelést.

Production hatás

Az exception típusok befolyásolják:

• a metrikákat
• a retry politikákat
• a tranzakció rollback viselkedést
• a REST hibaleképezést
• a support vizsgálatokat

Amint éles rendszereket üzemeltetsz, a rossz exception taxonómia nagyon láthatóvá válik.

8. Interjúkérdések

Mi a különbség az `Error` és az `Exception` között?

Az Error általában súlyos rendszerproblémát jelez, amelyből az alkalmazás nem szokott normál módon helyreállni, míg az Exception olyan állapotot jelez, amelyet az alkalmazáskód kezelhet vagy továbbadhat.

Mi a különbség a checked és unchecked exception között?

A checked exceptiont el kell kapni vagy deklarálni kell, míg az unchecked exceptionnek nem kell megjelennie a szignatúrában, és általában programozói hibát vagy szerződésszegést jelez.

Mikor használnád az `IllegalArgumentException`-t?

Akkor, amikor a hívó érvénytelen értéket ad át egy metódusnak, és ezzel megsérti az előfeltételeket.

Miben más az `IllegalStateException`?

Azt jelzi, hogy az objektum vagy a rendszer rossz állapotban van a kért művelethez, akkor is, ha az átadott argumentumok egyébként érvényesek.

Miért kell megőrizni a cause-t?

Mert a magasabb szintű exception az aktuális absztrakción értelmezi a hibát, miközben a cause megőrzi az alacsonyabb szintű technikai okot a hibakereséshez.

9. Szószedet

10. Cheatsheet

• A Throwable főként Error és Exception ágakra bomlik.
• A checked exception explicit kezelést vagy deklarációt kényszerít ki.
• Az unchecked exception jellemzően bugot, misuse-t vagy szerződésszegést jelez.
• Az IllegalArgumentException rossz inputról szól.
• Az IllegalStateException rossz objektum- vagy rendszerállapotról szól.
• Az Error általában nem üzleti folyamatkezelési kategória.
• A specifikus exception típus jobb kommunikáció, mint az általános.
• Fordításkor őrizd meg a cause-t.
• A típusválasztást a hívói felelősség és a helyreállítás alapján döntsd el.
• Interjún a szemantikát és a tervezési következményeket is magyarázd el.