Řada lidí je proti výjimkám. V Objective-C výjimky jsou, ale používají se minimálně, chybové stavy se idiomaticky řeší vrácením chybového objektu. Což je sice na první pohled pracné, ale zato jednoduché a explicitní. Swift v tomhle přístupu pokračuje, podobně jako třeba Go.
Takže je nutné zatěžovat návratovou hodnotu chybovými hodnotami. A pak je třeba taková maličkost, jako donutit programátory tyto chybové hodnoty číst a respektovat.
A až nastane chyba typu „není dostatek paměti“ nebo „přístup mimo platnou paměť“ nebo „nedostatek místa na zásobníku“, případně „dělení nulou“, apod., pak zajisté všechny funkce budou tyto hodnoty předávat do návratových hodnot. Jen musí nějak vymyslet, jak třeba to dělení nulou kód funkce odchytí.
Takto se tvoří programovací jazyka, které nejsou s to ošetřit základní stavy runtime prostředí, a bude ještě jednou velmi veselo.
Swift umí vrátit víc hodnot najednou, v Objective-C se chybový objekt obvykle vrací pomocí výstupního parametru. Ano, je s tím psaní, ale zároveň je to prakticky explicitní. Pokud se programátor nechce obtěžovat ošetřováním chybových stavů, výjimky ho nedonutí, viz klasický javový idiom „catch (Exception) {}“.
Nedostatek paměti se už teď signalizuje vrácením nulového ukazatele, tam není co extra řešit. Přístup mimo platnou paměť je prostě segfault, na tom není nic špatného. Dělení nulou už se dneska neřeší výjimkou, prostě se vrátí NaN.
Více hodnot najednou dne umí vrátit třeba i C++ nebo Python. A přesto mají výjimky, protože jejich autoři mysleli prakticky, ne ideologicky.
Nedostatek paměti může vzniknout i v podprogramu, který nevrací žádnou hodnotu. Třeba si podprogram alokuje buffer, přes který provede svou činnost, ale návratová hodnota nemusí být žádná.
Přístup mimo platnou paměť je snadno ošetřitelný pomocí výjimek, a může být použit i ke zjištění, zda je adresa platná. Třeba ve Windows takový přístup vyhodí výjimku jádra operačního systému, která se předá programu, a pokud je Windows program schopen si výjimku ošetřit, pokračuje se dále. To segfaultem neošetříte, tam to max. padne na hubu.
NaN je hodnota floating point čísla. Neexistuje na proměnných typu integer, stejně jako dalších. Tedy stále nemáte ošetřeno dělení nulou.
Jednoduše, v objektivní debatě byste prohrál názor, že výjimky nejsou třeba.
Považujete NASA za idioty? (Abych použil stejný argument, jako jsem dostal?)
Miloslav Ponkrác
Protože ne všechny chyby vznikají přímo v kódu. A pokud máte jazyk bez výjimek, tak s chybami, jejichž zdroj je mimo kód často nic neuděláte, a takový program jednoduše krachne na ústa, protože nic s tím dělat nemůže.
Pouze výjimky dovolují ošetřit skutečně maximum chybových stavů. Nic jiného.
Ministerstvo obrany USA a NASA se v minulosti velmi rychle přesvědčila, že pokud si do programovacího jazyka Ada nepřidají výjimky, budou mít ve zničených raketách škody ve stovkách miliard dolarů. Protože ovládací programy budou krachovat, kdykoli se vyskytne nečekaná věc a vezmou sebou i celou raketu, která se tím pádem stane neovladatelným kusem šrotu.
Váš pokud postavit 2 jména lidí s dotazem, jestli je považuji za idioty, budu ignorovat. To, že je někdo slavný neznamená, že se nemýlí, nebo nedělá občas chybná rozhodnutí nebo nemá chybnéí názory.
Navíc kolem Unixu vznikají mnohé názory, které jsou jasně spíše ideologického (tedy sektářsky motivovaného) důvodu, často proti praxi a užitku a racionalitě.
Znovu, mnoho chyb vzniká mimo kód. Hw je dnes čím dál složitější. Chyby v něm vznikají jak na běžícím pásu. Když nastane chyba v kontrolním součtu RAM, jinak, než výjimkou z toho nevybruslíte. Když vám začne docházet místo na zásobníku, když nějaký hw uprostřed operace nečekaně zkolabuje, nebo když se vyskytne cokoli neobvyklého, co nemá původ ve vašem zdrojovém kódu – bez výjimek program pouze pane na hubu, nic jiného nejde. S výjimkami je schopen, je-li to nutné, se z toho dostat a pokračovat bezchybně v běhu.
Bez výjimek prostě neuděláte tak spolehlivý sw, jako s nimi. Chápu, že začátečníci, kteří si myslí, že chyby vznikají pouze ve zdrojovém kódu, a proto se dají vždy vrátit a ošetřit jako návratové hodnoty funkcí, že pak výjimky jsou zbytečné.
Stejně tak ošetřování chyb pomocí výjimek je v každém případě přehlednější a účinnější.
On líbivý programovací jazyk, jako Swift nebo Go, je v podstatě jen vrtkavá móda. To jsou jazyky, které se dělají z marketinkových důvodů a z důvodů reklamy, ale praktické nejsou. Při jejich návrhu se nad jejich praktičností ani za mák nepřemýšlelo. Prostě neviditelná ruka trhu prodává také iluze, nejenom užitek.
Miloslav Ponkrác
hodne pismenek, qale celkem nesmysly. jen par malickosti:
1)pokud selhava hw, vetsinou to odstreli jakykoli kernel, temer libovolneho OS. nejake vyjimky na aplikacni urovni jsou irelevantni
2) par fault tolerant programu jsem videl, vesmes slo o soustavu procesu vzejemne se hlidajicich, master/slave watchdogy heartbeaty atd....pad binarky je v tomto kontextu zcela normalni resitelna vec, z letadla ani rakety se najednou srot nestane.
3) vyjimky jsou prevazne o falesnem pocitu bezpeci a vybizeji k lenive psanemu kodu bez vetsiho rozmyslu
Ad 1) Váš subjektivní názor předkládáte bez důkazů jako fakt.
Ad 2) Pokud považujete pád binárky za zcela běžnou věc, pak ok. Možná by mohlo uvědomit si, že nejsou jen „drsně fault tolerant systémy“ a pak „padací programy“, mezi tím je široká škála a široká potřeba různých spolehlivostí.
Ad 3) Výjimky jsou způsobem ošetřování chyb, jejichž možnosti nelze plně nahradit jiným způsobem. To, že jste lenivý programátor, to je Váš problém.
Ja jakozto admin tech ovyjimkovanych softu tvrdim, ze za kazdou vyjimku by bylo treba autorovi kodu zapichnou spendlik zcela kamkoli ... behem par dnu by byl casto ubodan k smrti.
Mockrat jsem totiz videl kod ve stylu "tak to zavolame a ono to nejak dopadne" ... aniz by dotycny vubec overil, ze parametr kde ma byt cislo to cislo skutecne je (a neni tam trebas kus textu) ... protoze ceka, ze mu to "kdyztak vrati vyjimku". Jenze ono treba taky nevrati ... a pak se dejou veci.
Zcela konkretne jsem narazil treba na to, ze autor si nacital pole hodnot ... misto podle nazvu podle poradi ... a kdyz dodavatel zdrojove aplikace pridal dalsi hodnotu ...
BTW: Neni to zas tak dlouho co se programovalo neobjektove, zcela bez vyjimek ... a kupodivu ty programy fugovaly velmi casto daleko spolehliveji nez cokoli dnes.