Programátoři chyby neignorují

A pak jsou taky chyby, které nijak zvlášť ošetřovat potřeba není a které zbytek kódu naopak ovlivnit nesmí. V odkazovaném článku uvádím třeba zvýšení počtu přečtení článku, v diskusi potom rozbor příkazů na jedné konkrétní stránce.

Výjimky jsou výborné v situaci, kdy chyba v jednom příkazu ovlivní chování dalších příkazů. Pokud je naopak potřeba chybu izolovat tak, že ostatní příkazy nesmí ovlivnit, tak to při používání výjimek vede k opakovanému psaní prázdných bloků try {} catch {}. A na to programátoři taky často kašlou, takže z lokálních chyb zbytečně vznikají globální.

#1 Jakub Vrána: psaní prázdných bloků try {} catch {} je snad ještě horší, než ignorování chyb indikovaných návratovou hodnotou.

Problém je, že ty v článku neuvádíš jako příklad chyby, kterou nijak zvlášť ošetřovat není potřeba, „zvýšení počtu přečtení článku“, ale „mysql_query“. Což je patrné nejen z článku, ale i následné diskuse.

A nějakou chytrou knihovničku jak to v PHP dělat a neupsat se při tom k smrti (což považuji při absenci výjimek a velmi bizardních návratových hodnotách u většiny bultin funkcí za reálné nebezpečí) bys neměl? 

Jo a ještě jedna rejpavá: „Tedy by alespoň by neměli. “ ← jedno „by“ by mohlo stačit. 

#2 David Grudl: Ale vůbec ne. Uvedl jsem pouze to, že zrovna u mysql_query by se někdy hodilo, aby vyhazovala výjimku (u chyb, které mají vliv na zbytek programu – tedy třeba načtení detailu článku) a jindy ne (třeba u oné inkrementace čítače, která by zbytek programu ovlivnit neměla). Z rozboru jedné konkrétní stránky vyplynulo, že lokálních chyb bývá převaha.

Uveď prosím kód pro inkrementaci databázového čítače, který používá databázovou funkci vyhazující výjimku.

#4 Jakub Vrána: A nebylo by lepší dávat sql dotazu jako další parametr něco ve smyslu „required“ (který by byl zároveň i výchozí) a při selhání by vyhodil výjimku, zatímco u inkrementování by se hodil False a prošlo by se třebas jen s Notice; popř. novou funkci (eg. dibi::easy() ), která by dělala to samé co require=False ?

#3 Pavel: některé knihovny lze k vyhazování výjimek přimět (například mysqli příkazem mysqli_report(MYSQLI_REPORT_ALL)), jindy se dá použít nadstavba, trošku experimentální je E_WARNING konvertovat na výjimky.

#4 Jakub Vrána: z rozboru té konkrétní stránky vyplynulo, že obsahuje 9 DB příkazů a pouze v jednom případě nekontroluješ návratovou hodnotu.

#6 David Grudl: Ale vůbec ne, to jsi pouze nepozorně četl. Návratovou hodnotu je naopak nutné kontrolovat pouze ve dvou případech, v sedmi případech je z pohledu uživatele vhodné, aby se s chybou pracovalo stejně jako v případě, že dotaz nevrátí nic (a z pohledu aplikace se chyba pouze zalogovala). Při použití výjimek by to znamenalo sedm prázdných try-catch nebo riziko eskalace lokální chyby na ostatní příkazy.

Můžeš prosím uvést ten kód pro inkrementaci databázového čítače, který používá funkci vyhazující výjimku?

Zajímavé počteníčko. Je však bohužel pravdou, alespoň z mého pohledu to tak je, že začínající programátory ukázky na PHP.net přímo k takovýmto krokům vedou.

Například jak bylo uvedeno u příkladu s funkcí fread – začínající „programátoři“ v PHP pak mohou nabýt dojmu, že je to tak v pořádku a není třeba nic ošetřovat.

#7 Jakub Vrána: v těch sedmi případech tedy nekontroluješ návratovou hodnotu funkce mysql_query a rovnou ji předáváš do mysql_fetch_assoc? V případě mysqli bys rovnou psal mysqli_query(...)->fetch_assoc()?

Kód máš ve svém článku.

Au.

Ten původní článek.

Au.

Nemám tě rád, nevěděl bych o něm.

Jakub je prostě bastlíř a jeho jediný problém je v tom, že se tím veřejně chlubí, píše bastlířské knihy a ještě to bastlení vyučuje.

V době jazyka C by si ani neškrtl. V době PHP je z něj internetová celebrita a vzor začínajících programátorů :(

#1 Jakub Vrána: „Pokud je naopak potřeba chybu izolovat tak, že ostatní příkazy nesmí ovlivnit“
V takových případech je lepší napsat wrapper který API třetí strany schová, pokud jde o vlastní kód nezbývá než refaktorovat a bloky kódu nižší úrovně logiky zabalit do funkcí.

#7 Jakub Vrána: Není pak přehlednější napsat dvě funkce, které budou splňovat požadované chování?

#1 Jakub Vrána: Bohužel PHP je dosti benevolentní a když něco vyhazuje výjimku, tak ji programátor ošetřit nemusí, narozdíl třeba od Javy, která v tom případě neumožní překlad. Pokud tedy jde o vytváření globálních chyb z lokálních je to opět záležitost PHP, v Javě se musí metoda označit explicitně klíčovým slovem throws, aby výjimka probublala výš (a to i v případě ručního volání throw).

I když bych tedy měl psát několik „prázdných“ bloků try-catch, tak mi to přijde programátorsky čistší. Skoro to vypadá, že ti jde o vlastní pohodlí, než o bezpečnost kódu 

Mnohé tu již bylo řečeno.
#13 Martin Hanák: Ještě dodám, že toto se týká často z nepochopitelného důvodu kritizovaných řízených výjimek (např IOException). Neřízených výjimek (IllegalArgumen­tException, NullPointerEx­ception, …) se to netýká, protože u správného kódu obvykle nenastávají a ošetřovat je by bylo peklo.

Tyto dva články a dnešní noční update mě inspirovaly k jednomu dotazu: co takhle nějaké bezpečné polykání výjimek (s logováním) u továrniček v Nette? Anotace NonCritical, nějaká sorry šablona?

Panuje obecné přesvědčení, že výjimky jsou ten nejlepší způsob zpracování chyb. Můj článek pojednává o tom, že v některých případech výjimky příliš výhodné nejsou a šikovnější je reportování chyb pomocí návratové hodnoty. Konkrétně jde o případy, kdy chyba v jednom příkazu nesmí ovlivnit ostatní příkazy.

Každou potenciální chybu je samozřejmě potřeba náležitě ošetřit a ať čtu článek a navazující diskuse jak chci, nikde nevidím, že bych tvrdil opak. Jde jen o to, že u izolovaného příkazu je ošetření chyby při použití návratové hodnoty (a zalogovaného varování PHP) zadarmo.

Řekněme, že chceme SQL příkazem zvýšit čtenost článku a pokud u toho dojde k chybě, tak tím nechceme otravovat uživatele, ale pouze programátora (pomocí chybového logu):

<?php
// v pořádku - pokud dojde k chybě, tak se zaloguje
mysqli_report(MYSQLI_REPORT_ERROR); // zapnutí varování pro SQL příkazy (na ostrém se logují)
mysqli_query($mysqli, "UPDATE ... ctenost = ctenost + 1 ...");

// teď je to bastlení - může dojít k nezachycené výjimce
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); // zapnutí výjimek pro SQL příkazy
mysqli_query($mysqli, "UPDATE ... ctenost = ctenost + 1 ...");

// v pořádku, pouze je kód poněkud krkolomnější
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
try {
        mysqli_query($mysqli, "UPDATE ... ctenost = ctenost + 1 ...");
} catch (mysqli_sql_exception $e) {
        // bez tohoto řádku by šlo taky o bastlení
        error_log($e);
}
?>

Při použití výjimek se tedy dá bastlit úplně stejně jako při použití návratové hodnoty. Dost už tedy prosím těch keců o bastlení, pokud se chyby ošetřují pomocí návratové hodnoty.

#9 David Grudl: Já jsem po tobě chtěl ten kód proto, že protestuješ proti prázdným blokům try-catch.

#14 v6ak: O jakém nočním update mluvíš?

#15 Jakub Vrána: aha… všimni si, že s prvním odstavcem nikdo nepolemizuje, namátkou #5 Pavel: navrhuje udělat „tichou“ variantu jinak výjimkové mysql_query + řada podobných komentářů u tebe v diskusi. Je dáno kontraktem metody, jak bude chybu hlásit a návratové hodnotě se nikdo nebrání.

Co nazývám bastlením je poslední odstaveček se zmínkou, že chyby indikované návratovou hodnotou lze ignorovat a program bude nejspíš nějak pracovat. Tedy v kontextu článku, že s výjimkami je vše mnohem složitější. Nezachycená výjimka je menší zlo, než skončit s nekonzistentními daty a ještě vypadat, že je vše ok.

#16 Jakub Vrána: ovšem ani tam prázdný catch není – je tam logování. Nicméně protestoval jsem proti systematickému psaní prázdných catch via #1 Jakub Vrána:.

#17 David Grudl: Opravdu bych nečekal, že se celá kauza nakonec vysvětlí tím, že nepochopíš psaný text. Poslední odstavec mého článku je holé konstatování faktu. Není to nějaký návod nebo doporučení, že něco lze, je to jen popis skutečného chování. A vysvětlil to už Bronislav Klučka v první reakci na Martina Hrušku, který to jako první nepochopil.

Já jsem dokonce napsal reakci, kde jsem Martinu Hruškovi doporučil přestěhování do Severní Koreje, pokud chce lidi střílet za prosté konstatování faktu. Nicméně po vysvětlení Bronislava Klučky mi přišla zbytečná, a tak jsem ji nepublikoval.

#17 David Grudl: Je třeba v Dibi nějaká obdoba metody query, která nevyhodí výjimku? Nevidím ji. Můžu si do modelu napsat metodu, která vrací třeba výběr článků a v případě výjimky vrátí false? To je nevhodné, protože na stránce určené výhradně pro výpis výběru článků je výjimka žádoucí. Naopak je nežádoucí na stránce, kde chci zobrazit komponentu s výběrem článků. Takže buď si můžu do modelu napsat metody dvě, nebo v prezenteru použít „návrhový vzor“:

<?php
try {
        // tady bude jeden příkaz
} catch (Exception $e) {
        error_log($e);
}
?>

A tento „návrhový vzor“ použít u všech komponent, které pro zobrazení stránky nejsou kritické.

A opravdu bych chtěl vidět kód nějaké větší aplikace, kde se z chyb v SQL příkazech vytváří výjimky, jestli tento „návrhový vzor“ poctivě používá u všech nekritických komponent. Vsadil bych si totiž na to, že řada z nich na to bude kašlat, takže bude zbastlená právě proto, že používá výjimky místo návratové hodnoty.

Už jsem to psal jinde, ale proč by měl jeden výběr selhat a jiný ne? Standardně v 99% proběhnou správně oba výběry a nebo ani jeden z nich (např z důvodu poruchy databáze)

K tomu příkladu výše: pokud je to tedy nutné, co si do metody modelu přidat další nepovinný parametr, kterým by se určilo zda-li výjimku vyhodit nebo ne? Myslím si ale, že pokud je nutné často používat výše uvedený „návrhový vzor“, tak je chyba někde v návrhu aplikace a ne v tom, že bez výjimek by to bylo jednodušší.

Programuji nebo programoval jsem i v JSP a ASP.NET, tam se to výjimkami jen hemží. Např i každé konvertování řetězce na číslo je potřeba ošetřit. O desktopových aplikacích vůbec nemluvím, tam stačí maličkost a už máme fatal. Jen PHP se vždy musí chovat jinak.

Jednoznačně jsem tedy pro výjimky a souhlasím s Davidem.

Ukázali jsme si, že existuje alespoň jeden případ, kdy jsou výjimky příjemnější a alespoň jeden případ, kdy je příjemnější návratová hodnota. Na webu se možná vyskytuje druhá možnost častěji než jinde, ale ne tak často, jak by se mohlo na první pohled zdát, protože při dvou a více na sobě závislých operacích (např. query a fetch) se to bez nich již začíná komplikovat. U menších částí to bude ještě únosné, u větších to bude peklo.
Z vlastní zkušenosti bych neváhal, pokud bych z těchto dvou způsobů měl vybrat jeden univerzální a vybral bych výjimky.

Jinak konec souboru není zvykem řešit výjimkou, i v Javě je to návratovou hodnotou: http://download.oracle.com/…tStream.html#…

Pravda, i v Javě se občas vyskytují věci, nad kterými zůstává rozum stát, např. http://download.oracle.com/…io/File.html#… , ale na řešení metody read jsem ještě stížnost neviděl.

#16 Jakub Vrána: Na jednom webu jsme dělali update a já byl po ruce pro případ, že by byl problém. Dostali jsme se k nějakému problému s DB, která ale postihla i ErrorPresenter. Krásný příklad toho, že se hodí udělat nekritické části webu. A lazy připojení. Zároveň jsem se dostal k myšlence, že ona neelegantnost výjimek by šla vyřešit, kdyby se jednotlivé bloky nekritického potenciálně problematického kódu uzavřely do speciálních metod volaných nějakým systémem, který by v případě nekritických metod jen napsal chybovou hlášku a zalogoval výjimku.
U komponenty může taková chyba nastat hlavně u render a v továrničce. Bylo-li by nekritickým komponentám přiřazeno takovéto chování, snížilo by to význam reportování chyb návratovou hodnotou hodně blízko k nule.

#18 Jakub Vrána: že nepochopím psaný text se může docela dobře stát, o tom žádná. Aby ses nezlobil, mám pro tebe námět na dobře míněnou radu: „V PHP nemusíte kód odsazovat a můžete ho dokonce vtěsnat na jeden řádek.“ Holý fakt, za ten se nestřílí a Pythonisti můžou závidět 

#19 Jakub Vrána: V Dibi obdoba metody query, která nevyhodí výjimku není. Proč? Odpovím ti (odpovíš si) hned, jak odpovíš na #9 David Grudl:. Stále jsem v očekávání.

Mimochodem, bastlíř je v původním slova smyslu totéž, jako byl v původním slova smyslu hacker. Když už to ale používáme jako negativní přívlastek – myslíš si, že aplikace ukončená nezachycenou zalogovanou výjimkou představuje větší zlo, než aplikace tiše páchající nekonzistenci dat? (otázka je obecná a netýká se zobrazení stránky tvého blogu).

#9 David Grudl: To už jsem dávno napsal ve své diskusi.

#22 David Grudl: Menší zlo je samozřejmě aplikace ukončená nezachycenou výjimkou. Stejně tak se ale dá položit otázka, jestli je lepší aplikace ukončená nezachycenou výjimkou kvůli chybě v nepovinné komponentě nebo aplikace, která tuto chybu zaloguje a komponentu pouze nezobrazí.

Já nikde netvrdím, že výjimky jsou pro ošetření chyb nevhodné. V některých situacích jsou samozřejmě velmi užitečné. Jindy jsou ale spíš na obtíž a vedou k psaní neelegantního kódu.

#23 Jakub Vrána: ten kód jsem chtěl vidět jako protiargument k #7 Jakub Vrána: že návratovou hodnotu je nutno kontrolovat takřka ve všech případech. Což je samozřejmě správně, ukazuje to na povahu mysql_query jako nízkoúrovňové funkce a pokud by vyhazovala výjimku, jediný rozdíl v kódu by byl v záměně if (!$result) na catch (DbException $e). Výhoda výjimky je v tom, že zapomeneš-li, nenastane větší zlo (a co je větší zlo jsme se shodli). A z pohledu elegance mám rád mysqli_query(...)->fetch_all().

Tvému přeformulování otázky se nijak nebráním. A s posledním odstavcem zcela souhlasím. Kdyby zazněl ve tvém článku, nevznikne tento.

Tu vášnivou diskuzi jsem nečetl, nicméně myslim, že z těch ukázek v článku je krásně vidět, že PHP se nedá s klidem použít na něco seriózního.

#22 David Grudl: Vezměme to z druhého konce. Když čtenář nepochopí myšlenku pisatele, tak je to často chyba pisatele, obzvlášť když je takových čtenářů víc. Beru to tedy tak, že jsem napsal článek, který mohl být špatně pochopen. Doplnil jsem do něj nyní drobný dovětek s odkazem na tento článek, který celkové vyznění snad trochu vyváží.

Proč se mi ukázky zdají nevhodně vybrané a jak je to s těmi příklady u funkce fread: Jak je to s těmi chybami?

http://poll.pollcode.com/Hm7p

nechtělo se mi číst ten flame tady, všichni to jistě víte, ale ne každý si to při psaní reakce uvědomil:

vyjímka (narozdíl od chyby) přeruší control-flow – skočí někam úplně jinam (do try-catch a nebo do exception handleru) a pokud jazyk nepodporuje rescue (jako např. ruby), tak nejsou vždy nejlepším řešením – protože už se prostě nikdy nedostanu zpátky. (pokud nepíšu na každém řádku try-catch – všem obhájcům vřele doporučuju zkusit programovat v javě, tam si vyjímek tak užijete, že se ještě rádi vrátíte.

#26 Tonda: no jasně, zlato, tak si běž plakat někam jinam…

#30 vedouci: V Javě jsem si výjimek užil a dal bych si ještě Ačkoli se najdou věci, které bych v Javě změnil (a většinou jsou změněné v JavaFX Scriptu), ale u výjimek bych toho moc neměnil.

#32 v6ak: dej vedet za rok, za dva ;)

#33 vedouci: Od seznámení s Javou už přes dva a půl roku uplynulo…

#20 Proki: Kde to mam podepsat?

Ad dgx vs. Jakub : Co blbnete, roztrhejte si obcanske prukazy Presne jak je psano v #20, v 99% pripadu na webu to bud projde cely nebo nic. O zbytek nema imho smysl se hadat a provozovateli casto jde predevsim o tu drtivou vetsinu se snadnou moznosti upravy kodu, nez o slozity/nepreh­ledny, byt radoby100% kod.

#11 Milan Prokeš: Vykrik do tmy bez reakce. Nechapu duvod, proc sem vsichni motaji C nebo Javu. Kdybych chtel tridu zacit psat s tunama getteru / setteru, pustim se do toho. Jsem linej a pisu v PHP. Imho je cesta nekde uprostred, tj. nejspis co popisuje Jakub: corebusiness vyhazovat na vyjimky, „kraviny“ napsat jednoduse. PHP mi umoznuje si vybrat, java, C, C# me tlaci do striktnosti – jo, sem linej a … to uz sem rikal 

#20 Proki: Kde to mam podepsat?

Ad dgx vs. Jakub : Co blbnete, roztrhejte si občanské průkazy Přesně jak je psáno v #20, v 99% případů na webu to buď projde celý nebo nic. O zbytek nemá imho smysl se hádat a provozovateli často jde především o tu drtivou vetšinu se snadnou možností úpravy kódu, než o složitý/nep­řehledný, byť rádoby100% kód (o ten jemu často navíc nejde vůbec).

#11 Milan Prokeš: Výkřik do tmy bez reakce. Nechápu důvod, proč sem dotyční motají C nebo Javu. Kdybych chtěl třídu začít psát s tunama getterů / setterů, pustím se do toho. „Jsem línej a píšu v PHP, zastřelte mě“ :) .

Imho je cesta někde uprostřed, tj. nejspíš co popisuje Jakub: v corebusiness vyhazovat na výjimky, „kraviny“ napsat jednoduše. PHP mi umožňuje si vybrat, Java, C, C# me tlačí do striktnosti – jo, sem línej a … to už sem říkal 

Kdyby byly všechny jazyky stejný, tak by logicky stačil jeden a my bychom to měli jednoduchý. K čemu mít 10 stejných jazyků, které by se lišily jen syntaxí? IMHO nesmysl. Každý se hodí na něco jiného a zdá se, že ve své oblasti se uchytily, jelikož přežily dost dlouho…