Co byste dělali, pokud by při volání metody A došlo k…

V závislosti na typu výjimky a obchodní logice:

Zpracování výjimky (try-catch): Zachyťte výjimku v bloku catch a proveďte odpovídající logiku:

Záznam chyby.
Zobrazení zprávy uživateli.
Pokus o zotavení nebo pokračování v práci (například poskytnutí výchozí hodnoty).
Převod výjimky na jinou, vhodnější (z Checked na Unchecked nebo naopak).

try {
    methodA();
} catch (SpecificException e) {
    // Záznam chyby
    logger.error("Chyba při volání methodA", e);
    // Můžeme zobrazit zprávu uživateli
    // displayErrorMessage("Došlo k chybě");
    // Nebo se pokusit zotavit
    // handleRecoveryLogic();
} catch (AnotherException e) {
    // Zpracování jiného typu výjimky
} finally {
    // Kód, který se provede za všech okolností (uvolnění zdrojů)
    // closeResource();
}

Předání výjimky (throws): Pokud metoda A nemůže s výjimkou sám zacházet, předá ji volající metodě pomocí klíčového slova throws. Ta ji buď zpracuje, nebo předá dál.
```
public void methodB() throws SpecificException {
    methodA(); // methodA může vyvolat SpecificException
}
```
To platí, pokud výjimka vyžaduje zpracování na vyšší úrovni abstrakce.
Ignorování výjimky (nedoporučuje se): Zachytit výjimku a nedělat nic. To je špatná praxe, protože skrývá chyby a ztěžuje ladění. Zřídka je to odůvodněné pro méně závažné výjimky, které neovlivňují chod programu.
```
try {
    methodA();
} catch (Exception e) {
    // Ignorovat... velmi špatný nápad ve většině případů
}
```
Přerušení provádění: Pokud je výjimka fatální a další práce je nemožná, lze ji nechat se rozšířit nebo výslovně vyhodit novou výjimku, například RuntimeException, pokud je třeba zastavit tok provádění.

Volba závisí na kontextu, typu výjimky (Checked vs Unchecked) a politice zpracování chyb v aplikaci. Je důležité, aby zpracování výjimek bylo konzistentní a poskytovalo dostatečné informace pro ladění.

Co byste dělali, pokud by při volání metody A došlo k výjimce?