Způsobuje separaci místa vzniku chyby od místa jejího zpracování, a to i vertikálně, přes úrovně jednotlivých vrstev, což je IMO zlo. [...] A tak se na to kašle, nechá se to zpropagovat až kdo ví kam a tam se teprve chyba řeší. Jenže takové místo je z hlediska struktury, tj. viditelnosti a rozsahu platnosti jednotlivých entit, izolované od místa vzniku. Vlastně už se tam nedá dělat nic, než jen vzít na vědomí, že "někde dole" vznikla chyba
...což je přesně to, co u velkého množství programů chceš. Nějaký velký blok kódu řeší jednu věc, například načtení credentials, připojení na server, autentizace. Nechceš řešit všechny možné chybové stavy u všech jednotlivých kroků. Chceš na nejvyšší úrovni dostat informaci "nemohl jsem se připojit, protože ..." (nelze se připojit k DB, credentials jsou neplatné, server je nedostupný apod.)
Kdybys měl opravdu na každém místě řešit úplně všechny chybové stavy, ke kterým může dojít (včetně lowlevel věcí jako např. "out of memory" apod.), tak v té změti checkování bude ten samotný algoritmus jako jehla v kupce sena.
Asi záleží, co kdo dělá. Ve svém oboru (embedded, průmyslová automatizace) jsem vypozoroval, že to není, co chci. Buď budu chybové stavy řešit poctivě, což je u robustních aplikací naprosto nezbytné, ale pak výjimky nepřinášejí žádný benefit, jen se celý kód zaprasí try/catch smetím, a to jak na zdrojové, tak na strojové úrovni, nebo se to bude řešit implicitní propagací chyb, ale pak si do programu zanesu špatně definované, "nelexikální" stavy, což je v tomto oboru naprosto nepřijatelné - takový model ošetření chyb se nedá pořádně ani zauditovat, protože není bezkontextový.
Chyba se musí ošetřit co nejblíže místu, kde vznikla, nebo propagovat explicitně jako reinterpretovaná chyba vyšší vrstvy.
Netvrdím, že výjimky nemají své místo. Umožňují naprasit program, který nakonec vždycky skončí alespoň s vědomím, že se někde něco podělalo, místo aby program dále rozvíjel chybný stav. Ono to dokáže člověka naštvat i u nevinné aplikace, jako třeba nějaký EDA nástroj, kdy někde nějak špatně pohneš myší a celé to spadne na nějaké takové výjimce a půl hodiny práce je v..., zatímco správně ošetřená, lokalizovaná chyba tohoto typu by neměla mít na chod celé aplikace tak fatální následky. Ale u robustní aplikace je takové chování nepřijatelné.
Ano, považuji za normální testovat chybu na místě vzniku, i za cenu "znepřehlednění" algoritmu. Tvorba programu je inženýrská činnosti a inženýr by měl být s takovými situacemi srozuměn a schopen se v nich orientovat. Výmluvy tohoto typu mi připadají podobně absurdní, jako tvrdit, že všelijaká ložiska, těsnící kroužky, gufera, pružiny, podložky, olejové kanálky apod. "znepřehledňují" návrh spalovacího motoru. Jsou zkrátka jeho součástí a samozřejmě, že reálný, prakticky fungující motor je oproti školnímu dřevěnému modelu složitější a tak trochu se v něm ten vlastní princip ztrácí. Tak to prostě v životě je.
Zrovna nedávno jsem psal jeden takový modul, kdy jsem si říkal, že ty testy chybových stavů tvoří většinu kódu. Přirozeně to člověka dokopalo k refaktoraci, po níž je kód i bez použití výjimek naprosto přehledný, z hlediska (chybových) stavů dobře analyzovatelný a přitom robustní.
Mám takový pocit, že výjimky jsou jedním z mechanismů, jež pomáhají činit nevhodně navržené programy životaschopnými. Ale nejsem přesvědčen o tom, že to je dobře.
71 Odpovědí
15989 Zhlédnutí