Proč ten hype okolo Go?

[oss]

[
Pro mě otevření souboru, který neexistuje, není žádná výjimka. Je to normální situace jako každá jiná, není tedy důvod na ni reagovat nějakým jiným mechanismem. Dělení nulou? Buď je to bug v mém programu, nebo opět normální situace - to když tu nulu nějak zadal uživatel. Index mimo meze dtto.

Pokus o otvorenie suboru, ktory nejestvuje je vynimocny stav pre metodu, ktora sa ma postarat o jeho otvorenie, respktive precitanie, lebo neokaze vykonat to co ma.

Potom su pripady, ked nexistencia suboru je ocakavany stav, ale vtedy sa to riesi  tym, ze si clovek nasjkor odtestuje existenciu suboru.
PS: pride mi semnticky nezmyslne pre tetovanie existencie suboru ho otvrat.
Obdobne je to s parsovanim vstupu od pouzivatela. Treba pouzivat metody, ktore nehadzu vinimku.

[Reklama]

[JS]

K vyjimkam vs. navratovym kodum:

Existuji tri zakladni typy zpusobu, jak osetrovat chybove stavy:

• Navratove hodnoty - je to jednoduche, citelne, nizky overhead, ale musi se osetrit lokalne
• Vyjimky - citelnost je horsi, ale neni nutne chybu osetrovat lokalne, ztraci se kontext v dusledku odvinuti zasobniku
• Error handlery (treba condition system) - vyssi overhead, chybu neni nutne osetrit lokalne, zachovava kontext protoze neodviji zasobnik

Vetsina jazyku nema moznost 3 (C sice error handlery v jakesi forme umi ale vicemene je to dost omezene, protoze v Unixu je to omezene). Nektere (Go?) nemaji v podstate ani moznost 2.

Z pohledu jednoduchosti a citelnosti programu (nikoli ovsem nutne kratkeho zapisu) je 1>2>3. Na druhou stranu, z pohledu flexibility a moznosti je 3>2>1. Neni zadny vitez ani porazeny.

[oss]

Bod 2 mas zle. Vynimky si prave zo sebou ten kontext maju niest (napriklad stak trace, dodatocne informacie,...).

[Bacsa]

Nektere (Go?) nemaji v podstate ani moznost 2.

Go má výjimky.

[Kit]

Pro mě otevření souboru, který neexistuje, není žádná výjimka. Je to normální situace jako každá jiná, není tedy důvod na ni reagovat nějakým jiným mechanismem. Dělení nulou? Buď je to bug v mém programu, nebo opět normální situace - to když tu nulu nějak zadal uživatel. Index mimo meze dtto.

S tímto přístupem bys výjimku nepoužil nikdy, vše by bylo normální situací. Výjimka je jazykovým konstruktem, který má za úkol usnadnit programátorovi práci tak, aby se mohl soustředit na to, co má program dělat.

Kontextem mám na mysli lexikální kontext - a ten předáním nějakého objektu prostě neobnovíš. Co je mi platné, že mám kompletní informace o výjimce, když z daného místa se na ni efektivně nedá reagovat jinak, než vyhodit to do nějakého logu a případně se zhroutit? Nebo mám do výjimkového objektu nacpat i reference na vše, čeho se ta výjimka týká, tím si ten lexikální kontext totálně rozbít a zamotat do toho ještě kontext dynamický - podle toho, zda dojde k výjimce? No děkuju pěkně!

Výjimku zachytím v místě, kde ten kontext ještě není narušen.

Ten článek je zcestný - psal ho někdo, kdo objektově neprogramuje. To je také důvod, proč mu výjimky nevyhovují. Není tam uvedena žádná ukázka správně napsaného kódu.

Tak ukaž příklad nějakého správně napsaného kódu. Když jsem sem postnul jiný článek, reagoval jsi stejně - špatné použití výjimek. A jak je to tedy správně?

V C# neprogramuji, ale Java má přesně na tohle try-with-resources. V C# se pro uvolnění zdrojů používá finally, pokud nevymysleli něco lepšího.

[Reklama]

[Kit]

Potom su pripady, ked nexistencia suboru je ocakavany stav, ale vtedy sa to riesi  tym, ze si clovek nasjkor odtestuje existenciu suboru.
PS: pride mi semnticky nezmyslne pre tetovanie existencie suboru ho otvrat.
Obdobne je to s parsovanim vstupu od pouzivatela. Treba pouzivat metody, ktore nehadzu vinimku.

Pokud se uživateli zobrazí seznam souborů, ze kterých si kliknutím má vybrat, který chce otevřít, tak je zbytečné testovat jeho existenci. Je však i hodně případů, že i samotná existence souboru nese vhodnou informaci a není nutné ho otevítat. V takovém případě je testování existence v naprostém pořádku.

Pokud parsuji chybný vstup od uživatele, tak výjimky používám zcela běžně. Předpokládám, že když je nějaký uživatel vůl, tak je to výjimka.

[Bacsa]

V C# neprogramuji, ale Java má přesně na tohle try-with-resources. V C# se pro uvolnění zdrojů používá finally, pokud nevymysleli něco lepšího.

Vymysleli, C# má using/IDisposable.

[Bacsa]

Předpokládám, že když je nějaký uživatel vůl, tak je to výjimka.

  Mně to přijde spíš jako naprosto běžná situace.

[JS]

Bod 2 mas zle. Vynimky si prave zo sebou ten kontext maju niest (napriklad stak trace, dodatocne informacie,...).

Nemam. Vyjimky odviji zasobniky, a proto v miste zpracovani vyjimky nemas treba lokalni promenne. Tenhle problem prave resi error handlery, ktere se volaji z mista chyby (vicemene) a vytvari novy frame na zasobniku (aniz by likvidovaly puvodni). Coz dovoluje to treba restart primo v miste, kde chyba vznikla (protoze se error handler muze vratit do funkce, ktera vyvolala chybovy stav), ale ma to i svoje nedostatky (vyssi overhead zpracovani chyby).

Bohuzel z historickych duvodu (hlavne diky vlivu Unixu) se na error handlery jako moznost zapomnelo. Ale v jazycich mimo Unixovou tradici, jako PL/I a Common Lisp, se normalne daji pouzit.

[Miloslav Ponkrác]

Testování existence souboru před otevřením má tři zásadní problémy:

1) Zbytečný další přístup na disk, zbytečná další pomalá I/O operace.

2) Po otestování existence souboru a před otevřením se může cokoli stát: Někdo může soubor vymazat, apod.

3) Selhání otevření souboru má mnohem více příčin než jen jeho neexistenci: nejsou práva, soubor je zamčen, poškozená data na disku, vyčerpání limitu počtu otevřených souborů, soubor nelze otevřít v požadovaném režimu, atd. atd. atd.

[JS]

Nektere (Go?) nemaji v podstate ani moznost 2.

Go má výjimky.

Go uz si tolik nepamatuji, ale co se tak zbezne divam na panic() etc. (jestli to je to co myslis), tak to je asi spis kategorie error handler nez vyjimky.

[Bacsa]

Nektere (Go?) nemaji v podstate ani moznost 2.

Go má výjimky.

Go uz si tolik nepamatuji, ale co se tak zbezne divam na panic() etc. (jestli to je to co myslis), tak to je asi spis kategorie error handler nez vyjimky.

Myslím panic/recover. Funguje podobně jako longjmp. Jak už tu někdo psal, používá se pro ošetření panicu v gorutině, aby nepadl celý program (udělá se stack unwinding a pak se může ošetřit chyba, nicméně uvolňování různých zdrojů by měl řešit defer, takže spíš se prostě ten panic utlumí, aby program pokračoval).

[Miloslav Ponkrác]

Tenhle problem prave resi error handlery, ktere se volaji z mista chyby (vicemene) a vytvari novy frame na zasobniku (aniz by likvidovaly puvodni). Coz dovoluje to treba restart primo v miste, kde chyba vznikla (protoze se error handler muze vratit do funkce, ktera vyvolala chybovy stav)

A jak často je ten restart užitečný? Jednou za miliardu let?

Pokud se v rámci ošetřování chyby (jedno jestli analýzou návratové hodnoty nebo výjimky) chci vrátit zpět, tak jednoduše zopakuji operaci znovu. Je to levnější a jistější.

Každý způsob ošetřování chyby má své plusy a mínusy. A vždy je ošetřování chyb hnusné, nepohodlné a narušuje tu původní krásu kódu, která předpokládá, že vše proběhne bez chyby. Polovina pouček, dogmat a ideologií jak psát správně kód se ukáže k ničemu, jakmile se důkladně začnou ošetřovat chyby.

1) Návratový kód je levný, ale blokuje nebo omezuje návratovou hodnotu pro chybové stavy, nikoli pro užitečnou informaci, kterou chceme vrátit z podprogramu. Ošetřování chyb vede k rozkošatělému stromu podmínek kolem volání funkce. Ještě horší nečitelnost programu v tomto případě pak dostáváme, pokud se důsledně nepoužívá goto, ať to stojí co to stojí.

2) Výjimky mají svůj název proto, že jsou "výjimkami z předpokládaného běhu programu", tedy z cesty, kdy vše je sluníčkové a bez chyby. Nejde tedy o "výjimečnou situaci", jak kdosi psal. Výjimky dokáží ošetřit i stavy, které návratové kódy z funkcí nedokáží. Výjimky navíc vyhazuje i samotný procesor, takže to skutečně funguje od lowest level až po highest level.

[Miloslav Ponkrác]

Výjimky zavádějí speciální stav - chybový. Ale co to je? Chci otevřít soubor, který mezi tím někdo smazal - je to chyba, nebo jiný možný stav? Uživatel zadá ve výrazu dělení nulou - výjimka, nebo normální možný stav? Někde v nějakém cyklu se mi index dostane mimo meze - výjimka nebo možný stav? V tomto případě asi přímo chyba v programu.. K čemu ale výjimky mají sloužit? K ladění, nebo k reakci na nějaké stavy, které z nějakého důvodu chci ošetřovat jinak než jiné stavy?

To je zase demagogie! Výjimky nezavádějí žádný další stav. Výjimky jsou pouze jedním z dalších řídících příkazů, které umožňují přenést vykonávání kódu na jiné místo, jako jsou podmínkové příkazy, cykly, skoky, volání podprogramu.

Považujete podmínkový příkaz (if) za definici nového chybového stavu programu? Měl byste při vaší demagogii. Protože dělá to samé, co výjimka. Přeskakuje vykonávání části kódu. Výjimka to jen dokáže v kontextu mezi podprogramy, nic více a nic méně.

Chápu určité výhody výjimek - zvláště při ladění, ale jinak je považuji za syntaktický balast. V případě ladění je to ale jen takový drahý assert, v případě normální reakce je to zvrácené - některé stavy ošetřovat klasicky, jiné úplně jinak - a jako "bonus" dochází ke ztrátě komtextu. Ta koncepce výjimek se mi prostě nelíbí.

To raději přestaňte programovat úplně. Například kontext ztrácíte kdykoli vyskočíte z podprogramu a kdykoli vyskočíte z nějakého bloku programu, který ukončuje platnost lokálních proměnných v něm definovaných.

Pokud by vám vadila řízená ztráta kontextu, pak jediné, co vám pomůže je: Všechny proměnné globální, žádné podprogramy, atd. atd. atd.

[era]

A správně je to jak? Ona základní potíž spočívá ve správné klasifikaci chybového stavu. Bez výjimek s tím problém není, protože není rozdíl mezi stavy. Výjimky zavádějí speciální stav - chybový. Ale co to je? Chci otevřít soubor, který mezi tím někdo smazal - je to chyba, nebo jiný možný stav? Uživatel zadá ve výrazu dělení nulou - výjimka, nebo normální možný stav? Někde v nějakém cyklu se mi index dostane mimo meze - výjimka nebo možný stav? V tomto případě asi přímo chyba v programu.. K čemu ale výjimky mají sloužit? K ladění, nebo k reakci na nějaké stavy, které z nějakého důvodu chci ošetřovat jinak než jiné stavy? A proč?

Chápu určité výhody výjimek - zvláště při ladění, ale jinak je považuji za syntaktický balast. V případě ladění je to ale jen takový drahý assert, v případě normální reakce je to zvrácené - některé stavy ošetřovat klasicky, jiné úplně jinak - a jako "bonus" dochází ke ztrátě komtextu. Ta koncepce výjimek se mi prostě nelíbí.

Je více druhů výjimek (pomáhám si z knížky Framework Design Guidelines):

Usage error

Programátor něco napsal špatně. Například ArgumentNullException když programátor předává někde null referenci tam kde neměl. Tyto výjimky se neošetřují (pouze například na nejvyšší úrovni) a slouží k tomu aby se objevily a ošetřily chyby v kódu projevující se až za běhu programu.

Execution error

Chyba které nelze zabránit v kódu i když je napsaný správně. Například, pokud chcete smazat soubor, tak ověříte jestli soubor existuje, ale než jej potom smažete, tak za tu chvilku už může být odstraněný. Tyto vyjímky se potom dají rozdělit na:
     
    Program error - který jde ošetřit v kodu pomocí try catch, například FileNotFoundException a dát třeba hlášku uživateli.
   
    System failure - nelze ošetřit programově, například chyba JIT překladače.