Best practice

A jó exception design világos jelentést, megfelelő absztrakciót és diagnosztizálható hibautakat ad.

1. Definíció

Az exception best practice arról szól, hogyan tervezz kivételosztályokat és hibautakat úgy, hogy a rendszer érthető, karbantartható és megfigyelhető maradjon. Interjún ezt gyakran custom exception, exception translation és message design példákon keresztül mérik fel. A téma túlmutat a szintaxison: architekturális döntés, hogy egy adott réteg milyen kivételt dob, mit csomagol be, és mennyi részletet szivárogtat kifelé.

2. Alapfogalmak

Fogalom	Jelentés	Miért fontos
Custom exception	Saját domain jelentésű kivétel	Pontosabb hibaszemantikát ad.
Exception translation	Alsóbb szintű kivétel átfordítása magasabb absztrakcióra	Elrejti az infrastruktúra részleteit.
Cause chaining	Eredeti kivétel megtartása cause-ként	Diagnosztikához kritikus.
Fail fast	Hibás állapot korai jelzése	Kisebb hibatérrel könnyebb debugolni.
Actionable message	Értelmezhető hibaüzenet	Segíti az operációt és a fejlesztést.

• A custom exception akkor jó, ha domain jelentést hordoz, nem csak új nevet ad ugyanannak a problémának.
• Az exception translation tipikus repository → service vagy external client → domain boundary mintázat.
• Az eredeti kivételt soha ne veszítsd el feleslegesen; láncold be cause-ként.
• A kivételüzenet legyen rövid, pontos és diagnosztikailag hasznos, de ne tartalmazzon érzékeny adatot.

3. Gyakorlati használat

A(z) Best practice 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.

• Definiálj saját kivételt, ha a hívó fél ettől tud értelmesebben dönteni, például InsufficientFundsException vagy OrderNotFoundException.
• Fordítsd át az alacsony szintű technikai kivételt a réteg határán. Például SQL kivételből lehet domain vagy alkalmazás kivétel.
• Ügyelj rá, hogy a logolás és a dobás ne duplikálja feleslegesen ugyanazt minden rétegben.
• Interjún jó válasz, ha kiemeled: exceptiont ne használj normál vezérlési ághoz.

4. Kód példák

Egyszerű példa

public class OrderNotFoundException extends RuntimeException {
    public OrderNotFoundException(String orderId) {
        super("Order not found: " + orderId);
    }
}

Haladó példa

public class OrderService {
    private final OrderRepository repository;

    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }

    public Order load(String id) {
        try {
            return repository.findById(id);
        } catch (DatabaseException ex) {
            throw new OrderAccessException("Failed to load order: " + id, ex);
        }
    }
}

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
Saját kivételosztály	Pontos domain jelentés	Túlhasználva felesleges osztályszaporulat lesz
Exception translation	Tisztább réteghatárok	Cause megőrzése nélkül információvesztést okozhat
Részletes hibaüzenet	Jobb diagnosztika	Érzékeny adat kiszivárgásának kockázata

6. Gyakori hibák

• ❌ Rossz: Új kivételt dobsz az eredeti cause nélkül. ✅ Helyes: Mindig láncold be az eredeti kivételt, ha releváns.
• ❌ Rossz: Technikai kivételt közvetlenül kiszivárogtatsz a domain API-ból. ✅ Helyes: Fordítsd át a megfelelő absztrakciós szinten.
• ❌ Rossz: Exceptionnel vezérled a normál üzleti folyamatot. ✅ Helyes: Normál elágazáshoz használj visszatérési értéket vagy állapotot.

7. Senior szintű meglátások

Senior szinten a kivételek a rendszer nyelvének részei. Egy jó exception hierarchy segít a monitoringban, a hibastatisztikában és a support folyamatokban is.

Follow-up kérdés: checked vagy unchecked legyen a custom exception? Erre nincs univerzális válasz; a döntést az határozza meg, hogy a hívó tud-e reálisan recoverelni.

A legjobb exception design rétegtudatos: más információ kell a végfelhasználói hibaüzenethez, más a loghoz és más a fejlesztői diagnosztikához.

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

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

Valós rendszerekben a kivételtervezés a support és az observability minőségére is hat. Ha a domain kivételek beszédesek, a cause lánc megmarad, és a logolás nem duplikált, akkor egy incident vizsgálata sokkal gyorsabb, mint egy olyan rendszerben, ahol minden réteg ugyanazt az általános RuntimeException-t dobja.

8. Szószedet

Kifejezés	Jelentés
custom exception	Saját definíciójú kivételosztály domain jelentéssel.
exception translation	Alsóbb szintű kivétel átfordítása magasabb réteg nyelvére.
cause	Az eredeti kivétel, amit becsomagolva megőrzünk.
fail fast	Hibás állapot korai jelzése.
actionable message	Olyan üzenet, ami alapján lehet cselekedni vagy diagnosztizálni.

9. Gyorsreferencia

• Custom exception csak akkor, ha új jelentést ad.
• Őrizd meg a cause-t.
• Fordítsd át a kivételt réteghatáron.
• Ne szivárogtass érzékeny adatot hibaüzenetben.
• Exception nem normál control flow eszköz.

Ha interjún elakadsz, a(z) Best practice 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.