Doporučené postupy v programování - Návrh procedur, funkcí a metod

# Základní terminologie

## Rutina

- obecný koncept umožňující seskupovat související kód
        - omezuje duplicitu, poskytuje základní nástroj pro abstrakci
        - parametry, lokální proměnné, návrat do místa volání

## Specifické druhy rutin

- Procedury
        - Funkce
        - Metody

Note:

Primárním účelem funkcí je typicky spočítat nějakou hodnotu jako
        funkci vstupních parametrů. Opravdu čistých funkcí se v typickém
        programu asi najde málo, pokud to není program ve funkcionálním
        jazyce. Hlavní charakteristikou funkcí je absence vedlejších efektů,
        což má celou řadu výhod. Nicméně z pohledu běžného programátora se
        čistě funkcionální programování může jevit poměrně málo intuitivní.

Procedury jsou typické pro imperativní styl programování, kdy má
        programátor absolutní kontrolu nad průběhem výpočtu. Procedury obecně
        reprezentují aktivitu a výsledkem procedury není hodnota, ale např.
        přechod systému do jiného stavu. Přestože řada procedur vrací nějakou
        hodnotu a čistě syntakticky se jedná o funkce, svou povahou jsou to
        stále procedury.

Nakonec jsou metody, což jsou procedury a funkce svázané s daty.

# Proč vytvářet procedury a funkce?

## Omezení složitosti
        - skrývání informací, abstrakce
            - flexibilita změny implementace
            - odsun zavlečené složitosti
        - přiblížení řeči zadání – zlepšení čitelnosti
            - zjednodušení booleovských testů

## Zamezení duplikace
        - zlepšení udržovatelnosti
        - možnost parametrizace
        - obecnější koncept – **<abbr lang="en" title="Don't Repeat Yourself">DRY</abbr>**

## Zvyšování výkonnosti
        - důsledek abstrakce a zamezení duplikace

</div>

Note:

V základních kurzech programování se člověk typicky dozví, že
        procedury a funkce slouží hlavně k zamezení duplikace kódu, cehož
        důsledek je především to, že se program lépe vyvíjí, ladí,
        dokumentuje a udržuje. Vedle syntaktických detailů jak používat
        parametry a lokální proměnné se toho člověk víc moc nedozví.

Přestože takové vysvětlení v každém bodě říká pravdu, zdaleka se
        nedotýká např. mnohem důležitějšího aspektu a tím je zvládání
        složitosti s využitím abstrakce a skrývání informací. Zamezení
        duplikace kódu samo o sobě typicky nepřináší všechny zmiňované výhody
        – ty právě plynou až z dobře strukturovaného programu, přimž
        vhodná struktura nevznikne sama od sebe pouhým naskládáním kódu do
        procedur a funkcí.

# Příklad: párovost operací zamykání

## Součástí výkonného kódu

```c++ stretch bad-code
        uintptr_t alloc_pages (...) {
          lock (pgalloc_lock);
          ...
          // do something
          ...
          if (status = FAILURE) {
            unlock (pgalloc_lock);
            return;
          }
          ...
          // do something else
          ...
          if (status = FAILURE) {
            return;
          }
          ...
          unlock (pgalloc_lock);
        }
        ```

</div><div class="fragment">

## V nadřazené funkci

```c++ stretch good-code
        static
        uintptr_t __alloc_pages (...) {
          ...
          // do something
          ...
          if (status = FAILURE) {
            return NULL;
          }
          ...
          // do something else
          ...
        }

uintptr_t alloc_pages (...) {
          uintptr_t result;

lock (pgalloc_lock);
          result = __alloc_pages (...);
          unlock (pgalloc_lock);

return result;
        }
        ```

</div></div>

# Problém jednoduchých operací

Častou překážkou při vytváření procedur, funkcí
        a metod bývá pocit, že pro triviální operace nemá cenu vytvářet funkce,
        zvlášť pokud se neopakují.

</div>

## V čem spočívá trivialita?

- složitost implementace neodráží složitost konceptu
            - inkrementace proměnné vs. přidělení unikátního identifikátoru

</div><div class="fragment">

## A jak je to s tím opakováním?

- pokud se kód neopakuje, neznamená to, že nepatří do funkce
        - naopak, funkce dává prostor k pojmenování bloku kódu
            - vyšší úroveň abstrakce v místě volání, blok není nutné komentovat

</div><div class="fragment">

## A co s režií na volání funkce?

- počítejte s tím, že překladač i procesor je rozumný
        - nesbírejte výkonnostní drobky, pokud to není nutné

</div>

Note:

Pokud se opakují, není co řešit. Pokud se neopakují, dostáváme se
        do šedé zóny – je nutné zvážit zda se opakovat v principu mohou
        a jak ovlivňují soudržnost té konkrétní metody (viz. funkční
        soudržnost později).

Režie na volání funkce se není třeba bát. U kratších funkcí (zvlášť
        pokud jsou statické a používají se z jednoho místa) se dá očekávat, že
        překladač kód funkce zainlinuje a k žádnému volání nedojde. Když už
        k němu dojde, dá se očekávat, že parametry funkce (pokud jich není
        příliš) budou předány v registrech.
        
        Volání funkce není pro procesor tak "nepříjemné" jako podmíněný
        skok, takže i když je volání nepřímé, překladač může adresu skoku
        "spočítat" (tj. natáhnout z virtuální tabulky metod do registru) ve
        vhodný okamžik, takže v okamžiku zpracování instrukce volání (resp.
        nepodmíněného skoku na hodnotu v registru) už je jasné, kam se bude
        skákat. U moderních procesorů je navíc rozumné počítat s tím, že se
        snaží rozumně vykonávat operace spojené s voláním virtuálních metod,
        které jsou pro software typické.

# Jak nemá vypadat metoda?

## Routine from Hell

```c++ bad-code stretch
        void HandleStuff( CORP_DATA & inputRec, int crntQtr,
           EMP_DATA empRec, double & estimRevenue, double ytdRevenue,
           int screenX, int screenY, COLOR_TYPE & newColor,
           COLOR_TYPE & prevColor, StatusType & status, int expenseType )
        {

int i;
        for ( i = 0; i < 100; i++ ) {
           inputRec.revenue[i] = 0;
           inputRec.expense[i] = corpExpense[ crntQtr ][ i ];
           }
        UpdateCorpDatabase( empRec );
        estimRevenue = ytdRevenue * 4.0 / (double) crntQtr;
        newColor = prevColor;
        status = SUCCESS;

if ( expenseType == 1 ) {
             for ( i = 0; i < 12; i++ )
                   profit[i] = revenue[i] - expense.type1[i];
             }
        else if ( expenseType == 2 ) {
                  profit[i] = revenue[i] - expense.type2[i];
                  }

else if ( expenseType == 3 )
                  profit[i] = revenue[i] - expense.type3[i];
                  }
        ```

# Jak se pozná silná a slabá soudržnost?

## Ideální forma soudržnosti

* funkční soudržnost
            - metoda dělá právě jednu věc odvoditelnou z názvu
            - <span class="good-code">`sin(), getCustomerName(), eraseFile(), ageFromBirthday(), ...`</span>

## Méně ideální formy soudržnosti

* sekvenční soudržnost
            - operace musí být v určitém pořadí, v jednotlivých krocích sdílí mezivýsledky
            - příklad: výpočet věku z data narození následovaný výpočtem doby do důchodu z věku
        * komunikační soudržnost
            - operace používají stejná data, ale jinak spolu nesouvisí
            - příklad: rutina vytiskne a reinicializuje sumární data
        * časová soudržnost
            - operace spolu nesouvisí, jen mají být vykonány ve stejné fázi běhu
            - příklad: posloupnost různých operací při inicializaci programu
            - problém najít název → koordinační metoda – pouze volá jiné metody

</div>

# Příklad: komentovaná explicitní závislost

## Se zjevnou závislostí a komentářem

```java stretch okay-code
        //
        // Compute expense data. Each of the routines accesses the member
        // data expenseData. DisplayExpenseSummary should be called last
        // because it depends on data calculated by other routines.
        //
        expenseData = initializeExpenseData (expenseData)
        expenseData = computeMarketingExpense (expenseData)
        expenseData = computeSalesExpense (expenseData)
        expenseData = computeTravelExpense (expenseData)
        expenseData = computePersonnelExpense (expenseData)
        displayExpenseSummary (expenseData)
        ```

Note:

Komentář k závislosti upozorňuje na nutnost specifického
        uspořádání a na riziko špatného výsledku při jeho nedodržení,
        ale není z něj jasné, proč je závislost (obzvláště v tomto
        případě) vůbec nutná. Pokud takový návrh nejsme schopni
        zdůvodnit, je pravděpodobně lepší se mu vyhnout.

# Příklad: komentovaná závislost

## Bez zjevné závislosti s komentářem

```java stretch okay-code
        //
        // The following calls must be in correct order. Inside the
        // taskReachedState method, the Task Manager may decide to
        // close the context which contains this task by calling the
        // HostRuntimeInterface.closeContext method.
        //
        // If the calls are not properly ordered, the Host Runtime will not
        // have been notified about the task's completion (the notification
        // happens in the notifyTaskFinished call) and will refuse to close
        // the context (throwing IllegalArgumentException).
        //
        // This would lead to a race condition.
        //
        hostRuntime.notifyTaskFinished(TaskImplementation.this);
        hostRuntime.getHostRuntimesPort().taskReachedState(
          taskDescriptor.getTaskTid(),
          taskDescriptor.getContextId(),
          processKilledFromOutside
            ? TaskState.ABORTED
            : TaskState.FINISHED
        );
        ```

Note:

Příklad je převzat ze [softwarového projektu](https://web.archive.org/web/20160127145517/http://been.ow2.org/) Davida Majdy.
        Pro demonstrační účely není podstatné, co přesně dělají metody
        `notifyTaskFinished` a `taskReachedState`, ale
        to, jak podrobně je chování v komentáři popsáno.

# Zásady pro práci s parametry

## Podobné parametry uvádějte ve stejném pořadí u všech funkcí

```c bad-code
        fprintf(stream, format,...)
        fputs(str, stream)
        ```

</div><div class="fragment">

```c good-code
        strncpy(dst, src, len)
        memcpy(dst, src, len)
        ```

</div></div>

## Vyhněte se nepoužívaným parametrům

- stejné jako u nepoužívaných proměnných
        - výjimkou je nutnost dodržení signatury
            - callbacky, zpětná kompatibilita, apod.

</div><div class="fragment">

## Neměňte vstupní parametry v těle metody

- sémantika parametru je zachována, umožňuje extrahovat blok kódu do metody
        - Java – `final`, C/C++ – `const`

</div>

Note:

Klíčová slova `const` resp. `final` často
        znepřehledňují kód a tak je málokdo používá. Při návrhu nových
        jazyků by možná stálo za úvahu dát parametrům sémantiku konstant
        automaticky, bez potřeby klíčového slova. V modernějších jazycích
        (Scala, Kotlin) naleznete klíčová slova `val` resp.
        `var`, která slouží k deklaraci konstatních resp. 
        modifikovatelných proměnných (instančních i lokálních, včetně
        parametrů funkcí a metod).

# Příklad: použití vstupních parametrů

## Vstupní parametr supluje pomocnou proměnnou

```java bad-code stretch
          float response (float inputSample) {
            sampleHistory.store (inputSample);

inputSample = 0.0f;
            for (int i = 0; i < coefficients.length; i++) {
              ...
              inputSample += coefficients [i] * sampleHistory.previous (i);
              ...
            }
            ...
            return inputSample;
          }
          ```
        
        </div><div class="fragment">
          
          ## Vstupní parametry jsou tabu (pro modifikaci)

```java good-code stretch
          float response (final float inputSample) {
            sampleHistory.store (inputSample);

float outputValue = 0.0f;
            for (int i = 0; i < coefficients.length; i++) {
              ...
              outputValue += coefficients [i] * sampleHistory.previous (i);
              ...
            }
            ...
            return outputValue;
          }
          ```

</div></div>

# Zásady pro práci s parametry

## Preferujte abstraktní typy

- rozhraní (interface) v jazyce Java
            - <span class="bad-code">`void printNames (ArrayList <String> names);`</span>
            - <span class="good-code">`void printNames (List <String> names);`</span>
        - platí i pro návratové hodnoty

## Vyhněte se booleovským parametrům

- v místě volání není vidět, co `true` nebo `false` znamená
            - <span class="bad-code">`int compareStrings (String s1, String s2, boolean caseInsensitive);`</span>
        - výjimkou jsou metody, kde je význam zřejmý z názvu
            - <span class="good-code">`setEnabled (boolean enabled)`</span>
        - nahradit výčtovým typem/konstantami nebo dvojicí metod

Note:

K interfacům a abstraktním typům: Viz *Effective Java: Programming
        Language Guide, Item 34*.

K booleovským parametrům: Náhrada výčtovým typem/konstantou má i
        výhodu flexibility v případě, že časem přibudou další možné hodnoty
        parametru. To se u boolovských parametrů docela často stává, více
        viz výstižně nazvaný článek [Booleans suck](https://nedbatchelder.com/blog/200507/booleans_suck.html).

# Zásady pro práci s parametry

## Vyhněte se použití více než 5–7 parametrů

- v případě potřeby použijte strukturovaný typ s vhodnou úrovní abstrakce
        - velké množství předávaných parametrů indikuje příliš silnou vazbu

## Předávejte parametry odpovídající poskytované abstrakci

- klasický problém – předat specifické hodnoty vs. celý objekt
            - předání celého objektu porušuje zapouzdření a zesiluje vazbu
            - předání celého objektu zvyšuje stabilitu rozhraní
        - důležitá je abstrakce, kterou funkce poskytuje
            - pokud očekává hodnoty, které jsou náhodou také v objektu, který ovšem s funkcí nesouvisí, předávejte hodnoty
            - pokud metoda očekává, že dostane do ruky objekt a něco s ním udělá, předávejte objekt

Note:

Při zkracování seznamu parametrů funkce náhradou několika atributů
        jednoho objektu celým objektem je dobré se zamyslet, zda je fakt,
        že funkci chcete posílat celý objekt náhoda nebo systematická
        záležitost. Náhoda se pozná tak, že při volání funkce nemáte vždy
        dotyčný objekt "v ruce" – v tom případě je lepší nechat
        seznam parametrů být, protože budete muset u některých volání
        funkce objekt uměle vytvářet. Naopak, pokud zjistíte, že to náhoda
        není, stojí za to se chvilku zastavit nad strukturou kódu –
        můžete např. přijít na to, že daná funkce by měla být metoda
        objektu, který jí posíláte.

# Obecná doporučení pro vracení hodnot

## Předčasný návrat používejte s rozvahou

- obecně komplikuje control-flow – porušuje princip single-entry/single-exit
        - výjimky: strážné podmínky (guard conditions) na začátku, konce nezávislých větví

## Používejte jednotný název pro proměnnou s výsledkem

- prefix vhodnější, např. `result`
            - analogie se značením input/output parametrů

## Vracejte prázdné kontejnery místo `null`

- test na prázdnost dokumentuje úmysl, test na `null` je implementační detail
        - pole, seznamy a kolekce obecně
            - kód iterující přes obsah funguje i s prázdným kontejnerem
            - nefunguje s `null` hodnotou: `HttpServletRequest.getCookies()`
        - pro samostatné hodnoty zvažte použití option typu

Note:

K prázdným polím vs. `null` viz *Effective Java: Programming Language Guide, Item 34*.

S podporou pro funkcionální programování přibyla v Javě od verze 8 
        třída `Optional<T>`, což je (immutable) kontejner na 1 hodnotu.
        Ve Scale je k tomuto účelu typ `Option<T>`.

# Výjimky vs. chybové kódy

## Chybové kódy

- typicky nutí k přetěžování významu návratových hodnot
        - v místě volání nemusí být vidět
            - pokud nejsou předávány ve výstupním parametru nebo strukturované
              návratové hodnotě, což zase typicky zvyšuje míru zavlečené složitosti
        - musí se ošetřit na místě, ale nic k ošetření nenutí
        - musí se explicitně propagovat do vyšších vrstev

## ... ale ...

- jsou používány už dlouhá léta
        - dají se použít vždy
        - nemají výraznější režii

</div>

Note:

Problematika výjimky vs. chybové kódy je složitější – my
        jsme se jí tu jen zlehka dotkli. Zájemcům o motivační diskuzi lze
        doporučit k přečtení následující články (v uvedeném pořadí):

1. [Joel Spolsky: Exceptions](http://www.joelonsoftware.com/items/2003/10/13.html)
        2. [Ned Batchelder: Exceptions vs. Status Returns](http://www.nedbatchelder.com/text/exceptions-vs-status.html)
        3. [Joel Spolsky: DoSomething()](http://www.joelonsoftware.com/items/2003/10/15.html)
        4. [Ned Batchelder: Exceptions in the Rainforest](http://www.nedbatchelder.com/text/exceptions-in-the-rainforest.html)

Ned Batchelder má hezký model toho, jak vypadá software v článku
        "Exceptions in the rainforest". Podle něj má software 3 vrstvy,
        shora C-B-A. Nejnižší (A = Adapting software beneath) přizpůsobuje
        jiný kód našim potřebám. Někdy jsou to low-level volání, pak se často
        používají chybové kódy, které je dobré převádět na výjimky.

Prostřední vrstva (B = Building pieces of your system, někdy také
        Business logic :-) slouží k vytvoření částí, ze kterých se skládá náš
        svět. Tady je prostor pro problem-specific koncepty, algoritmy a datové
        struktury. V prostřední vrstvě chceme být maximálně produktivní a chceme
        tady mít dobře čitelný kód.

Nejvyšší vrstva (C = Combining it all together) ví co se děje, takže
        typicky ví, co dělat s výjimkami. Výjimky neznamenají, že error handling
        bude najednou snadnější, ale znamenají, že chyby z vrstvy A se neztratí,
        a že nemusíme "špinit" vrstvu B tím, že bude předávat chyby výše, do
        vrstvy C.

Typicky pak vrstva A vesměs vyhazuje výjimky, vrstva B také, ale méně,
        a vrstva C primarne chytá výjimky a potenciálně něco užitečného dělá.

A protože software je fraktální, dá se tenhle model embeddovat do
        různých vrstvev.

# Výjimky vs. chybové kódy

## Kdy je vhodne používat výjimky?

- jasným kandidátem jsou opravdové funkce
            - funkce se používají ve výrazech, výsledky se explicitně netestují
            - k selhání může dojít v podstatě pouze v důsledku chyby programátora
            - většinou na ně nelze rozumně reagovat, podobné signálům
        - procedury pracující s okolím
            - stav okolního prostředí se může měnit asynchronně
            - k selháním nedochází v důsledku programových chyb
            - reakce je součástí návrhu → hlavní předmět "sporu" o výjimky
            - při prototypování je snadné obsluhu odložit, problém neztratí
        - obecně: pokud to zjednoduší nebo zpřehlední kód/návrh
            - nehodí se přetěžování významu návratové hodnoty
            - jiné mechanizmy předávání doplňkových informací jsou neohrabané

Note:

Co se týče toho zda výjimky používat, pro nastartování diskuze
        postačí již dříve zmiňovaná debata Joel Spolsky vs. Ned Batchelder.
        K tomu je např. zajímavá polemika na obhajobu chybových kódů od
        Douga Rosse:

- [Return-codes vs. Exceptions, Part 129](http://directorblue.blogspot.com/2004/05/return-codes-vs.html)
        - [Return-codes vs. Exceptions, Part 318](http://directorblue.blogspot.com/2004/06/return-codes-vs.html)
        - [Exceptions, Tunable Logging, and ...](http://directorblue.blogspot.com/2004/06/exceptions-tunable-logging-and.html)
        - [Return-codes vs. Exceptions, Part 516](http://directorblue.blogspot.com/2004/06/return-codes-vs_108757899333825996.html)

Základní pravidlo asi jako obvykle zní – pokud použití
        výjimek zjednoduší a zpřehlední kód, asi není co řešit. Důležité
        je pak používat výjimky správně používat. Nakonec asi není až tak
        podstatné, zda se používá to či ono, ale zda se programátor vědomě
        a systematicky věnuje obsluze abnormálních stavů.

# Zásady pro práci s výjimkami

## Používejte výjimky na odpovídající úrovni abstrakce

- systematické
        - flexibilita změny implementace
        - řetězení výjimek – exception chaining

## Ve výjimce detailně popište problém

- Včetně případných chybných hodnot parametrů/proměnných

## Vyhněte se prázdným `catch` blokům

- pokud "by nemělo nikdy nastat", vložit kód vyvolávající chybu
        - typicky assertion, více defenzivní programování (později)

Note:

K úrovni abstrakce: Viz *Effective Java: Programming Language Guide,
        Item 43: Throw exceptions appropriate to the abstraction*.
        To znamená, že výjimky, které metoda vyvolává by měly být na úrovni
        abstrakce odpovídající tomu, co metoda dělé, ne jak to dělá.

K detailnímu popisu problému: Viz *Effective Java: Programming Language
        Guide, Item 45*.

K prázdným `catch` blokům: Viz *Effective Java: Programming Language
        Guide, Item 47*.

# Java a výjimky

## Jazyková podpora

- příkaz `throw`, slouží k vyvolání výjimky
          - konstrukce `try-catch`, slouží k odchycení třídy výjimek
          - konstrukce `try-finally`, slouží k uvolnění prostředků při výjimce
              - nahrazeno konstrukcí `try-with-resources`, která se typicky používá se streamy

## Druhy výjimek

- checked
              - musí být v signatuře metody
              - volající je musí povinně odchytit, nebo deklarovat v signatuře
              - kontrolováno staticky při překladu
          - unchecked

</div><div>

## Hierarchie výjimek

</div></div>

# Kontrolované vs. nekontrolované výjimky

## Kdy používat kontrolované a nekontrolované výjimky?

- kontrolovaná výjimka vynucuje obsluhu u volajícícho
            - pokud může nastat i při správném použití metody a dá se očekávat, ze volající ji může rozumně ošetřit
            - pokud si nejste jisti nebo záleží na kontextu použití → nekontrolované
        - nekontrolované – chyby programátora
            - kontrola parametrů, indexů, ...
            - fatální chyby – něco je strašně špatně
            - výjimky, které bude obsluhovat jen málo volajících
            - zvýšený důraz na dokumentaci

Note:

Mnohem těžší na rozhodnutí je dilema kolem kontrolovaných a
        nekontrolovaných výjimek. Řada expertů je dnes považuje za omyl a
        doporučují vyhazovat pouze nekontrolované výjimky a kontrolované
        převádět na nekontrolované. Viz např. Bruce Eckel:

- [Does Java Need Checked Exceptions?](https://web.archive.org/web/20180516002915/http://www.mindview.net/Etc/Discussions/CheckedExceptions)

Celou debatu pak ale poměrně dobře shrnuje Brian Goetz na
        webu IBM developerWorks:

- [Java theory and practice: The exceptions debate](https://web.archive.org/web/20161118193007/http://www.ibm.com/developerworks/library/j-jtp05254/)

A poměrně dobrý návod poskytuje také Barry Ruzek na serveru Dev2Dev:

- [Effective Java Exceptions](https://www.oracle.com/technical-resources/articles/enterprise-architecture/effective-exceptions-part1.html)

# Mapování výjimek do Javy

## Eventuality a chyby

<br>

**eventualita (contingency)**

- Výjimečná, ale předpokládaná situace, která se dá popsat v
          pojmech odpovídajících zamýšlenému účelu funkce, a která vyžaduje
          alternativní zpracování na úrovni volajícího. Volající je na takovou
          situaci připraven a má strategii pro jejich řešení.

<br>

**chyba/porucha (fault)**

- Neplánovaná situace, která metodě znemožnila vykonat zamýšlenou
            funkci, a která nemůže být popsána bez znalosti implementace
            funkce.

</div><div>

## Hierarchie výjimek

</div></div>

## Jaké výjimky použít?

<table class="real">
          <tr>
            <th>Situace</th>
            <th>Eventualita/Contingecy</th>
            <th>Chyba/Fault</th>
          </tr>
          <tr>
            <th>Považováno za</th>
            <td>součást návrhu</td>
            <td>ošklivé překvapení</td>
          </tr>
          <tr>
            <th>Očekávaný výskyt</th>
            <td>předvídatelný, ale vzácný</td>
            <td>nikdy</td>
          </tr>
          <tr>
            <th>Koho to zajímá</th>
            <td>kód volající metodu</td>
            <td>lidi, kteří mají odstranit problém</td>
          </tr>
          <tr>
            <th>Příklad</th>
            <td>alternativní návratové hodnoty</td>
            <td>programové chyby, selhání hardware, konfigurační chyby, chybějící soubory, nedostupné servery</td>
          </tr>
          <tr>
            <th>Nejlepší mapování</th>
            <td>kontrolovaná výjimka</td>
            <td>nekontrolovaná výjimka</td>
          </tr>
        </table>

Note:

Zdroj: [Barry Ruzek: Effective Java Exceptions](https://www.oracle.com/technical-resources/articles/enterprise-architecture/effective-exceptions-part1.html)

# Kontrolované vs. nekontrolované výjimky

## Kontrolované výjimky vyvolávejte v situacích, kdy je možné zotavení

- vyhněte se zbytečnému používání kontrolovaných výjimek v situacích,
          ze kterých se volající nemůže dost dobře zotavit
        - častá transformace: kontrolovaná výjimka →
          testovací metoda + nekontrolovaná výjimka

## Nekontrolované výjimky vyvolávejte při programových chybách

- nesplněné preconditions metody, fatální chyby, ...

Note:

K náhradě kontrolovaných výjimek za nekontrolované: Dobrý příklad
        je metoda parsující text v nějakém jazyce. Text může v principu
        obsahovat chyby, a je žádoucí, aby metoda v tom případě vyhazovala
        výjimku. Pokud by tato výjimka byla kontrolovaná, musel by
        programátor výjimku odchytávat i v případě, že by si byl jist, že
        metodě předává syntakticky korektní text (např. automaticky
        generovaný). Lepší řešení je použít nekontrolovanou výjimku a přidat
        metodu, která bezchybnost textu otestuje a vrátí `true`
        nebo `false`.

Uvedený postup ale nelze použít vždy. Např. pokud bychom chtěli
        před smazáním souboru zkontrolovat, zda tento soubor existuje, může
        nám ho mezi testem a smazáním někdo "smazat pod rukama". Je tedy
        potřeba mít zaručen exkluzivní přístup k datům.

Ke kontrolovaným a nekontrolovaným výjimkám: Viz *Effective
        Java: Programming Language Guide, Item 40: Use checked exceptions
        for recoverable conditions and runtime exceptions for programming
        errors*.

K užívání kontrolovaných výjimek: Viz *Effective Java:
        Programming Language Guide, Item 41: Avoid unnecessary use of
        checked exceptions*.

Osobně se přikláním spíše k názoru, že kontrolované výjimky mohou
        být užitečné primárně ve vlastním kódu, kde si tím mohu zajistit,
        že nezapomenu na obsluhu nějakého chybového stavu. Vně svého kódu
        bych kvůli minimalizaci obtěžování konzumentů mého kódu vyhazoval
        výjimky nekontrolované. Ty je pak nutné velmi dobře zdokumentovat.
        Pro situace, kdy je možné provést test před voláním výkonné
        metody (a kdy se situace po volání testu nemůže změnit), bych se
        snažil mít k výkonným metodám vždy testovací metody. Výkonné metody
        by pak mohly vyhazovat nekontrolované výjimky (bylo by chybou
        programátora, že nezkontroluje, zda může výkonnou metodu volat).
        Pokud není možné test a vykonání operace rozumně oddělit, volil
        bych spíše nekontrolovanou výjimku, abych nezatěžoval konzumenta.
        Dá se očekávat, že konzument nejspíš bude můj kód nějak adaptovat a
        kontrolované výjimky si může na vlastním území zavést sám.