Fail-fast nebo Fail-tolerant?
Nálepky:
Zdá se, že heslo “fail-fast”, tedy vzniklou chybu ohlásit co nejdřív a běh programu ukončit, bylo a je po léta základní mantrou všech (Java?) vývojářů. Tento přístup má pro programátora při vývoji aplikace řadu nesporných výhod:
- chyby jsou detekovány rychle a je levnější je opravit
- příčina selhání je jasně viditelná a zdroj pádu většinou přestavuje zdroj vlastní chyby
- chyby nejsou zanedbávány – každá musí být opravena aby systém fungoval
Díky těmto výhodám se tahle technika velmi oblíbenou a intuitivně ji nasazujeme a používáme všude. Stejně tak i všichni okolo nás – od autorů aplikačních serverů, webových frameworků, až po tvůrce jednoúčelových knihoven. Odvrácenou stránkou této techniky je, že se jí těžko zbavuje ve chvílích, kdy o ni nestojíme.
Sami bychom měli chtít od SW odlišné chování v závislosti s jakým cílem aktuálně běží. Ve vývojovém a testovacím prostředí jednoznačně preferujeme fail-fast variantu, v produkci bude naopak naším cílem fail-tolerant chování.
Více o tomto tématu píše Jan Novotný na svém blogu v článku Fail-fast, nebo Fail-tolerant.
Myslim, ze uvahy ktore tam autor rozvija su dost naivne. Ako chce rozhodnut co je uz zavazny problem a co iba drobna chyba. Navyse aplikacie sa testuju v nejakom kontexte, napr. ze dajme tomu ze komponenta X,Y musi byt za behu pritomna. Jeho predstava, ze hociktora cast moze necakane zlyhat (tj dostat sa mimo vymedzene podmienky behu) znamena, ze by sa system musel testovat na vsetky mozne zlyhania jednotlivych casti a zistovat kedy je bezpecne pokracovat a kedy nie. Z predstava, ze system moze bezat len tak ciastocne mi beha mraz po chrbte. Ano ked ma Ferko Mrkvicka web tak mu to moze byt jedno ale pri inych aplikaciach by to mohlo mat uplne ine nasledky. Fail-tolerant sa ma dosiahnut dobrym navrhom systemu a nie tym, ze system ignoruje beh mimo vymedzenych podmienok.
Takisto uvahy o spring su mimo. Pokial nejaka komponenta nie je nutna pre beh inej da sa nastavit zavislost ako optional dependency. Predpokladam, ze autor nejakej komponenty ma rozumny dovod preco si mysli ze k behu svojej komponenty potrebuje aj komponenty A a B. A ked nie je mozne tento prvotny predpoklad splnit tak by rozumny clovke ocakaval, ze ani jeho komponentu nie je mozne inicializovat. Pride mi to ako podobnost s transakciami. Autor si mysli, ze je lepsie urobit co i len cast transakcie, podla hesla lepsie cosi ako nic. To, ze databaza bude potom nekonzistentna uz v jeho uvahach akosi absentuje.
Já jsem o podobném problému před časem psal z pohledu vývojáře PHP.