Használat

Az exception típusok ismerete önmagában nem elég. Az igazi mérnöki tudás ott látszik, hogyan használod a try, catch, finally, throw, throws, multi-catch és try-with-resources elemeket a megfelelő absztrakciós szinten.

1. Definíció

Mit jelent az exception használat?

Az exception használat azoknak a kódmintáknak az összessége, amelyek meghatározzák, hogy:

• hol észleljük a hibát
• hol kezeljük
• milyen cleanup történik
• hogyan adunk hozzá kontextust
• mi mehet tovább magasabb rétegbe

Java-ban ez jellemzően a következők körül forog:

• try
• catch
• finally
• throw
• throws
• try-with-resources
• multi-catch

Miért fontosabb ez, mint a szintaxis bemagolása?

Szinte minden Java fejlesztő fel tudja mondani a szintaxist.

A nehezebb kérdés az, hogy az exceptiont jó helyen kezeljük-e.

A rossz exception használat eredménye:

• lenyelt hibák
• duplikált logolás
• resource leak
• félrevezető vezérlési folyamat
• gyenge megfigyelhetőség
• törékeny helyreállítási logika

A jó használat őszintén kezeli azt, hogy valójában hol lehetséges értelmes helyreállítás.

Milyen a jó válasz?

Egy erős interjúválasz nemcsak azt magyarázza el, mit csinál az adott nyelvi elem, hanem azt is, mikor helyes használni.

Ez azt jelenti, hogy a szintaxist össze kell kötni a következőkkel:

• ownership
• resource kezelés
• absztrakciós határok
• diagnosztika

2. Alapfogalmak

2.1 `throw` versus `throws`

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

Ez a téma erősebb lesz, ha a nyelvi elemeket és a szándékukat külön is kimondod:

• throw — az az utasítás, amely ténylegesen eldob egy kivételt.
• throws — a metódusszignatúrában lévő deklaráció, amely a továbbadott checked exceptionöket jelzi.
• try — a hibára hajlamos kódrészt kijelölő blokk.
• catch — a megfelelő kivételtípushoz tartozó kezelő blokk.
• finally — olyan logika, amely normál és kivételes befejezésnél is lefut.
• try-with-resources — az AutoCloseable erőforrások preferált lezárási mintája.
• multi-catch — több kivételtípus egy közös kezelőben, ha ugyanaz a reakció.
• suppressed exception — másodlagos cleanup-hiba, amely az elsődleges kivételhez kapcsolódik.

Egy jó review- vagy interjúválasz nem csak azt mondja ki, mit csinálnak ezek az elemek, hanem azt is, miért pont azon az absztrakciós szinten vannak jó helyen.

A throw egy metóduson belül ténylegesen eldob egy exceptiont.

A throws a metódus szignatúrájában azt jelzi, hogy a metódus bizonyos checked exceptionöket továbbadhat.

public void read() throws IOException {
    throw new IOException("Read failed");
}

Ez apró szintaktikai különbségnek tűnik, de interjún jól látszik belőle, hogy valaki tényleg használja-e a nyelvet.

2.2 `try` és `catch`

A try blokk olyan kódot jelöl, amely hibát dobhat.

A catch blokk egy illeszkedő exceptiont kezel.

A fontos kérdés nem az, hogy „elkaphatom-e itt?”, hanem az, hogy „érdemes-e itt elkapni?”.

A jó lokális kezelés ott történik, ahol tudsz:

• helyreállni
• jobb absztrakcióra fordítani
• értelmes kontextust adni
• tiszta alternatív eredményt adni

Ha ezek közül egyiket sem tudod, az elkapás könnyen csak ront a kódon.

2.3 `finally`

A finally blokk akkor is lefut, ha a try sikeres, és akkor is, ha hibát dob.

Régebben gyakran ezt használták erőforrások lezárására.

Ma ezeknek az eseteknek nagy része jobb try-with-resources megoldással.

Ennek ellenére a finally ma is fontos lehet például:

• metrikamérés befejezésére
• ideiglenes állapot visszaállítására
• lock release-re bizonyos mintákban
• olyan cleanupra, amit nem fed le az AutoCloseable

2.4 Try-with-resources

A try-with-resources a Java ajánlott mintája az AutoCloseable erőforrások kezelésére.

try (BufferedReader reader = Files.newBufferedReader(path)) {
    return reader.readLine();
}

Ez jellemzően biztonságosabb és tisztább, mint a kézi lezárás finally-ban.

A suppressed exceptionöket is helyesen kezeli.

Ez a részlet haladó interjúkon különösen fontos.

2.5 Multi-catch

A multi-catch lehetővé teszi több exception típus közös kezelését, ha a reakció valóban azonos.

catch (IOException | SQLException exception) {
    throw new IllegalStateException("External dependency failed", exception);
}

Csökkenti a duplikációt.

Csak akkor jó, ha a kezelési logika tényleg ugyanaz.

2.6 Suppressed exception

Amikor try-with-resources esetén egyszerre történik két hiba:

• a fő művelet exceptiont dob
• és a close() is exceptiont dob

akkor a Java a fő exceptiont tartja meg elsődlegesnek, a lezárás hibáját pedig suppressed exceptionként eltárolja.

Ez az egyik fontos oka annak, hogy a try-with-resources jobb sok kézi cleanup mintánál.

2.7 Catch sorrend

A catch blokkoknak specifikusból általános irányba kell haladniuk.

catch (FileNotFoundException exception) { ... }
catch (IOException exception) { ... }

Ha fordítva írod, a specifikus blokk elérhetetlenné válik.

A compiler ezt jelzi, de a tervezési okot is érteni kell.

3. Gyakorlati használat

Ott kapd el, ahol valóban tudsz dönteni

Az egyik legjobb szabály:

ott kapj el exceptiont, ahol értelmes döntést tudsz hozni.

Ez lehet:

• retry
• fallback logika
• domain vagy API szintű hibára fordítás
• üzleti kontextus hozzáadása
• egy boundary lezárása, például controller vagy batch job szinten

Ha csak logolni és továbbdobni fogsz plusz érték nélkül, az gyakran zaj.

Fordítás boundary-knél

Az alacsony szintű kód gyakran infrastruktúra-exceptionöket dob.

A magasabb rétegeknek ezeket nem mindig kell közvetlenül láttatniuk.

Például:

• repository layer elkap SQLException-t
• service layer UserLoadException-t dob
• web layer ezt HTTP 503 vagy 500 válaszra képezi

Ez már használat és architekturális gondolkodás, nem csak típusismeret.

Try-with-resources előnyben

Try-with-resources-t használj például:

• stream-eknél
• reader-eknél
• writer-eknél
• JDBC erőforrásoknál
• socketeknél
• egyedi AutoCloseable implementációknál

Kevesebb boilerplate-et jelent, és jobban kezeli a lezárási hibákat is.

Ne használd normál vezérlési folyamatként

Az exception nem mindennapi branch mechanizmus.

Ráadásul elhomályosítja a happy path-et, ha gyakori normál állapotokat exceptionökkel modellezel.

Az olyan validációs hibák, amelyek gyakran előfordulnak, sokszor jobban modellezhetők explicit eredménytípusokkal.

Hasznos kontextussal dobj tovább

Néha a továbbdobás teljesen helyes.

De akkor javítson az absztrakción.

Rossz:

catch (IOException exception) {
    throw exception;
}

Jobb:

catch (IOException exception) {
    throw new IllegalStateException("Could not load startup configuration", exception);
}

4. Kód példák

1. példa — Egyszerű `try` / `catch`

try {
    service.call();
} catch (IllegalArgumentException exception) {
    System.out.println("Bad input: " + exception.getMessage());
}

Ez akkor jó, ha a hívó lokálisan tud reagálni.

2. példa — `finally`

Lock lock = new ReentrantLock();
lock.lock();
try {
    doWork();
} finally {
    lock.unlock();
}

Ez modern példa arra, hogy a finally ma is releváns.

3. példa — Try-with-resources

try (BufferedReader reader = Files.newBufferedReader(path)) {
    return reader.readLine();
}

Ez tipikusan jobb, mint a kézi lezárási logika.

4. példa — Multi-catch

try {
    externalCall();
} catch (IOException | SQLException exception) {
    throw new IllegalStateException("Dependency failed", exception);
}

Ez akkor jó, ha a reakció valóban azonos.

5. példa — Fordítás és továbbdobás

try {
    repository.loadUser(id);
} catch (SQLException exception) {
    throw new UserLoadException("Failed to load user " + id, exception);
}

Ez megvédi a magasabb rétegeket az alacsony szintű részletektől.

5. Trade-offok

A fő kérdés mindig az elhelyezés.

Melyik rétegben a legértelmesebb kezelni a hibát?

6. Gyakori hibák

1. Elkapás és ignorálás

catch (Exception exception) {
}

Ez elrejti a hibákat és tönkreteszi a megfigyelhetőséget.

2. Logolás és továbbdobás minden rétegben

Ha minden réteg ugyanazt a hibát logolja, az üzemeltetés zajt kap információ helyett.

3. Kézi resource lezárás ott, ahol try-with-resources jobb lenne

Ez gyakran leakhez vagy elvesző másodlagos hibákhoz vezet.

4. Túl tág catch használata

Egy túl általános catch elrejthet programozói hibákat vagy egymástól eltérő hibakategóriákat.

5. Multi-catch eltérő kezelési igényekre

A szintaxis kényelmes, de csak akkor helyes, ha a szemantikai reakció is azonos.

6. `finally`-ból exception dobása

Ez elfedheti az eredeti exceptiont és rontja a diagnosztikát.

7. Mélymerülés

Miért ennyire fontos a try-with-resources?

A try-with-resources nem csak tisztább szintaxis.

Jobb hibamodellel dolgozik.

Ha a fő művelet és a cleanup is hibázik, a Java mindkét információt megőrzi a suppressed exception mechanizmuson keresztül.

Ez valós hibakeresési előny.

Exception kezelés mint boundary design

A jó exception használat az architektúrát tükrözi.

Ahol elkapod a hibát, az gyakran az a hely is, ahol ténylegesen tiéd a döntés.

Ezért az exception kezelés sokszor design boundary kérdés, nem puszta szintaxis.

Operatív következmények

A használati minták befolyásolják:

• a duplikált logokat
• a riasztások minőségét
• a tranzakció rollback viselkedést
• a support diagnosztikát
• a retry stormokat

Ezért production rendszerben a rossz exception használat gyorsan láthatóvá válik.

Senior interjú nézőpont

Egy senior válaszban gyakran elhangzanak ilyen mondatok:

• „Ott kapom el, ahol dönteni tudok.”
• „AutoCloseable erőforrásnál try-with-resources-t preferálok.”
• „Boundary-knél lefordítom az alacsony szintű exceptionöket.”
• „Kerülöm a duplikált logolást, ha nem ad hozzá értelmet.”

Ezek ítélőképességet mutatnak, nem memoritert.

A cleanup a helyesség része

Sokan azt hiszik, az exception kezelés főleg a hibaüzenetekről szól.

A valóságban a resource cleanup és az állapotkonzisztencia legalább ennyire fontos.

Egy bent maradó lock vagy félig lezárt stream gyakran rosszabb, mint az eredeti hiba.

8. Interjúkérdések

Mi a különbség a `throw` és `throws` között?

A throw ténylegesen eldob egy exceptiont a metódustestben, míg a throws a szignatúrában jelzi, hogy a metódus milyen checked exceptionöket adhat tovább.

Mikor kell exceptiont elkapni?

Akkor, amikor helyre tudsz állni, megfelelőbb absztrakcióra tudod fordítani, érdemi kontextust tudsz adni, vagy egy boundary-n értelmes döntést tudsz hozni.

Miért jobb I/O-nál a try-with-resources?

Mert kevesebb boilerplate-et igényel, megbízhatóan lezárja az erőforrásokat, és a suppressed exceptionöket is megőrzi.

Mikor helyes a multi-catch?

Akkor, amikor több exception típus pontosan ugyanazt a kezelést kapja.

Miért veszélyes az elkapás és ignorálás?

Mert elrejti a hibákat, tönkreteszi a megfigyelhetőséget, és a diagnosztizálható problémát csendes rossz működéssé alakíthatja.

9. Szószedet

10. Cheatsheet

• A throw eldob, a throws deklarál.
• Ott kapd el a hibát, ahol valódi döntést tudsz hozni.
• AutoCloseable erőforrásokra try-with-resources-t használj.
• finally akkor kell, ha garantált cleanup vagy állapot-visszaállítás szükséges.
• A catch sorrend legyen specifikusból általánosba.
• Multi-catch csak valóban azonos kezelésre jó.
• Továbbdobáskor őrizd meg a cause-t.
• Kerüld az üres catch-et és a duplikált logolást.
• A cleanup helyessége ugyanolyan fontos, mint a hibaüzenet.
• Interjún a szintaxist kösd össze a réteghatárokkal és az operációval.