Frustrace ze stavu mainstreamových programovacích jazyků

[.]

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.

Na to existují rozdílné názory i mezi programátroskou elitou, jsou to dvě strany téže mince. A ano, pak se všichni diví, kolik že jsme měli těch bezpečnostních děr za minulý týden?

[Reklama]

[Mirek Prýmek]

jsou to dvě strany téže mince.

Co? Co je jedna strana a co druhá? A jaké jedné mince?

A ano, pak se všichni diví, kolik že jsme měli těch bezpečnostních děr za minulý týden?

Bezpečnostní chyby jsou imho nejčastěji špatné implementace nějakého algoritmu, špatná kontrola vstupů nebo mezí polí. Ani jedno není způsobeno jedním nebo druhý přístupem k chybovým stavům.

[Filip Jirsák]

A ano, pak se všichni diví, kolik že jsme měli těch bezpečnostních děr za minulý týden?

Kolik těch bezpečnostních chyb je v kódu, kde se chybové stavy ošetřují pomocí výjimek, a kolik jich je v kódu, kde jsou chyby předávané jako běžné návratové hodnoty subrutin a ošetřují se v základním flow programu?

[zboj]

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

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.

Tohle je trochu problém Go (až na OoM, to panikaří vždy v knihovně), protože výjimky (ve smyslu longjmp) sice má, ale kód z toho elegantní neleze. Proto třeba ve Swiftu přepsali knihovny tak, aby se daly používat stylem "do {try ...} catch {...}"s tím, že lze použít rethrow. Na ošetření chyb jsou ale stejně pořád nejlepší monády 

[Mirek Prýmek]

Tohle je trochu problém Go

Na Go jsem právě myslel, když jsem to psal. Ten jejich error handling mě fakt otravuje. Neexistence výjimek a generik mě osobně na Go vysírá nejvíc.

[Reklama]

[zboj]

Tohle je trochu problém Go

Na Go jsem právě myslel, když jsem to psal. Ten jejich error handling mě fakt otravuje. Neexistence výjimek a generik mě osobně na Go vysírá nejvíc.

Výjimky tam jsou. Ta generika jsou jiná otázka, je fakt, že pro někoho z FP může být jejich absence bolestná, ale jakmile se člověk naučí používat správně ta jejich rozhraní, tak se bez nich dá obejít.

[Mirek Prýmek]

Výjimky tam jsou.

Kde/jaky?

Ta generika jsou jiná otázka, je fakt, že pro někoho z FP může být jejich absence bolestná, ale jakmile se člověk naučí používat správně ta jejich rozhraní, tak se bez nich dá obejít.

Jasne no. Ale traity z Rustu to nejsou...

[zboj]

Výjimky tam jsou.

Kde/jaky?

panic/recover (jen jinak pojmenované výjimky)

[Mirek Prýmek]

panic/recover (jen jinak pojmenované výjimky)

Aha, na to jsem ještě nenarazil Na první pohled to nevypadá úplně blbě, problém je, že se to nikde nepoužívá - všude jsou ty explicitní návratový kódy.

[Pavel Stěhule]

panic/recover (jen jinak pojmenované výjimky)

Aha, na to jsem ještě nenarazil Na první pohled to nevypadá úplně blbě, problém je, že se to nikde nepoužívá - všude jsou ty explicitní návratový kódy.

Je tam jiný pattern - to co lze ošetřit jednoduše nebo ignorovat se řeší co nejblíž vzniku, nebo to spadne na FATAL, což by mělo typicky vést k ukončení aplikace. Mně to přijde praktický - nevyhazuje se vyjímka kvůli každé blbosti a chyby se ošetřují blízko vzniku. Je to pragmatický přístup, který bych sám preferoval - kód asi nebude hyper elegantní, ale zase se v tom nedají stavět kolosy na hliněných nohou.

[Mirek Prýmek]

chyby se ošetřují blízko vzniku

Což se dá dělat i s výjimkami, takže to není argument.

[Youda]

chyby se ošetřují blízko vzniku

Což se dá dělat i s výjimkami, takže to není argument.

Vyjimky se pouzivaji bezne, zalezi na chuti programatora.
Dival jsem se ted na par knihoven na GIThubu je toi tak pul na pul.
Error code v GO je obvykle struct i implementovanou error() metodou, taze je to defacto exception objekt pro chude.
Navic GO funkce podporuji navrat vice hodnot (obvykle payload + error struct), takze explicitni vyjimka neni potreba.

Vubec cele GO je Ccko, ktere prebira zakladni veci Jawy cestou chudeho muze.
Misto finally bloku deferred funkce, misto metody funkce nabindovana na struct, ducktyping like inheritance, interfaces, ktere simuluji tridni hierarchii.
Primitivni ale dostatecne reflection API

Navic luxusni goroutines s channely, to muze i Jawa zavidet, multi CPU core support na lusknuti prstu.
Kompilace mrknutim oka, vysledek nativni exac vez overheadu startu JVM

GO muze pomerne bezbolestne pouzivat cisty ceckar i cisty jawista

Na mele a lighweight veci velice pekna zalezitost, jsem z toho celkem nadseny.
Osobne GO pouzivam na mstech, kde jsem placal perlove skriptiky.

[Mirek Prýmek]

Navic GO funkce podporuji navrat vice hodnot (obvykle payload + error struct), takze explicitni vyjimka neni potreba.

Jak už rečeno, rozdíl oproti výjimce je ten, že chybový kód se musí explicitně checkovat. Výjimka se checkovat nemusí (ale může, stejně jako chybový kód, čili je "obecnější", "mocnější").

[BoneFlute]

Navic GO funkce podporuji navrat vice hodnot (obvykle payload + error struct), takze explicitni vyjimka neni potreba.

Jak už rečeno, rozdíl oproti výjimce je ten, že chybový kód se musí explicitně checkovat. Výjimka se checkovat nemusí (ale může, stejně jako chybový kód, čili je "obecnější", "mocnější").

No, u návratové hodnoty drtivé většiny nefunkcionálních jazyků je navíc ten problém, že se návratová hodnota nemusí vyzvednout. Což je, na rozdíl o výjimek, dost průšvih.

[Pavel Stěhule]

Navic GO funkce podporuji navrat vice hodnot (obvykle payload + error struct), takze explicitni vyjimka neni potreba.

Jak už rečeno, rozdíl oproti výjimce je ten, že chybový kód se musí explicitně checkovat. Výjimka se checkovat nemusí (ale může, stejně jako chybový kód, čili je "obecnější", "mocnější").

V GO je pattern pro ignorovaní návratového kódu - jediný rozdíl vídím v tom, že  běžné chyby v GO neprobublávají. Jinak obecnější, mocnější nástroje nemusí být ku prospěchu věci - mocnější programovací jazyky vyžadují programátory schopnější větší abstrakce a větší abstrakce může vést k menší názornosti kódu.