Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: ronaldknud 18. 08. 2017, 11:42:34
-
Zdravím, mám konkrétní otázku, ale nejdřív motivace. Všichni mají plnou hubu keců o DRY, KISS, LSP apod., ale když přijde na rozumnou implementaci, jazyky jen hážou klacky od nohy. Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj). Takže - jak řešíte generický ad hoc polymorfismus v OO jazyce bez typových tříd (beru OO obecně, předpokládají se rozhraní, dědičnost ne)? V Go to jde částečně přes typové aliasy, jen se pak vyžaduje explicitní přetypováváni, což zbytečně prodlužuje a znepřehledňuje kód. Swift by se mohl dostat blízko, až zavedou plánovaný operátor ~=, ale ten zas mimo macOS/iOS není moc schůdný (verze pro Linux zatím hapruje).
P.S. Dynamické jazyky tento problém nemají, proto jsou v kontextu této diskuze irelevantní.
-
Resim to tak ze pouzivam OO jazyk s podporou typovych trid - Scalu.
-
To jsou starosti...
Buď rád, že nemusíš řešit error handling pomocí On Error GoTo ErrorHandler
-
Ja to resim tak, ze se snazim co nejvic lidi premluvit, aby se naucili Haskell, ale to jsi asi nechtel slyset. :-)
Pokud ti to tak vadi, jedina sance asi je, najit si praci v jazyce, ktery tim problemem netrpi (Haskell, Scala) nebo nektery z dynamicky typovanych jazyku.
-
Ja to resim tak, ze se snazim co nejvic lidi premluvit, aby se naucili Haskell
Toto by byl ideální stav, záhadou mi ovšem je, proč tvůrci "velkých" OO jazyků (Java, C*, ...) takovou věc, co by jejich jazyk posunula kvalitativně o řád výš, ignorují.
-
Buď rád, že nemusíš řešit error handling pomocí On Error GoTo ErrorHandler
Na chyby jsou monády ;D
-
Buď rád, že nemusíš řešit error handling pomocí On Error GoTo ErrorHandler
GW-Basic, to už se dneska moc nevidí ;D
-
Já to řeším tak, že se snažím co nejvíce lidem vysvětlit, ať si nestěžují, když zároveň chtějí u svého programovacího jazyka zůstat.
-
Typové třídy neznám (ale časem se chci mrknout na Haskell, takže se k nim nejspíš dopracuji), ale jak si vedou v porovnání s Traity v Rustu? Obecně jsou mi prvky funkcionálního programování v tom jazyku velmi sympatické.
http://science.raphael.poss.name/rust-for-functional-programmers.html#traits-rust-s-type-classes
-
Pokud ti to tak vadi, jedina sance asi je, najit si praci v jazyce, ktery tim problemem netrpi (Haskell, Scala) nebo nektery z dynamicky typovanych jazyku.
A pak je samozřejmě možnost naučit se programovat, přestat prasit a najednou se v těch "hrozných" jazycích programuje skvěle. Ale to je staromódní přístup, který se dneska už moc nenosí.
-
Buď rád, že nemusíš řešit error handling pomocí On Error GoTo ErrorHandler
GW-Basic, to už se dneska moc nevidí ;D
Nene, prachobyčejné VBA 6.0...
-
Pokud ti to tak vadi, jedina sance asi je, najit si praci v jazyce, ktery tim problemem netrpi (Haskell, Scala) nebo nektery z dynamicky typovanych jazyku.
A pak je samozřejmě možnost naučit se programovat, přestat prasit a najednou se v těch "hrozných" jazycích programuje skvěle. Ale to je staromódní přístup, který se dneska už moc nenosí.
Prasit se musí, když jazyk takovou intuitivní a nadmíru užitečnou vlastnost nepodporuje.
-
Javascript + Flow je IMHO dostatečný mainstream.
-
Buď rád, že nemusíš řešit error handling pomocí On Error GoTo ErrorHandler
GW-Basic, to už se dneska moc nevidí ;D
Nene, prachobyčejné VBA 6.0...
Jj, zlatý vyžužlal bejsyk!
-
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html (http://www.antonis.de/qbebooks/gwbasman/onerror.html)
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
-
Buď rád, že nemusíš řešit error handling pomocí On Error GoTo ErrorHandler
Na chyby jsou monády ;D
Lepsi je gonada
-
Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj).
Tak zrovna koncepty z nového C++ se typovým třídám už vcelku blíží. Není to sice úplně ono, ale je to lepší, než by člověk čekal.
-
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html (http://www.antonis.de/qbebooks/gwbasman/onerror.html)
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
Popravdě, zrovna toto je strukturovanější přístup, než například v céčku s návratovými kódy a jejich (ne)testováním :-) ERR+ERL jsou vlastně taková poor man alternativa k objektu Exception a vůbec, já na BASICu vyrost (Atari Basic + geniální Turbo Basic). Takže i ten robot jim asi chodil :-)
-
Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj).
Tak zrovna koncepty z nového C++ se typovým třídám už vcelku blíží. Není to sice úplně ono, ale je to lepší, než by člověk čekal.
Akorát se nějak nedostaly do C++17.
-
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html (http://www.antonis.de/qbebooks/gwbasman/onerror.html)
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
Popravdě, zrovna toto je strukturovanější přístup, než například v céčku s návratovými kódy a jejich (ne)testováním :-) ERR+ERL jsou vlastně taková poor man alternativa k objektu Exception a vůbec, já na BASICu vyrost (Atari Basic + geniální Turbo Basic). Takže i ten robot jim asi chodil :-)
Návratové kódy: http://programujte.com/clanek/2006030305-rozhovor-s-bjarne-stroustrupem/ (http://programujte.com/clanek/2006030305-rozhovor-s-bjarne-stroustrupem/) ;D
Copak přístup, s tím ON... se dalo dělat ledacos, ale z RESUME jsem tenkrát málem vypelichal. Zlatý ZX BASIC na Didaktiku. A je škoda že aspoň v QBasicu k tomu ON PEN nepřidali i ON MOUSE, světelné pero už tenkrát měl asi málokdo, zato když jsem si psal program pro myš, musel jsem do strojáku.
-
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html (http://www.antonis.de/qbebooks/gwbasman/onerror.html)
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
Je to vyžužlal!
-
Jsou dva typy programatoru. Jedni co programovat umi a druhy co se vymlouvaj na vse ostatni co s programovanim souvisi i nesouvisi.
-
Jsou dva typy programatoru. Jedni co programovat umi a druhy co se vymlouvaj na vse ostatni co s programovanim souvisi i nesouvisi.
Bohužel těch prvních je nás málo ;D
-
Zdravím, mám konkrétní otázku, ale nejdřív motivace. Všichni mají plnou hubu keců o DRY, KISS, LSP apod., ale když přijde na rozumnou implementaci, jazyky jen hážou klacky od nohy. Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj). Takže - jak řešíte generický ad hoc polymorfismus v OO jazyce bez typových tříd (beru OO obecně, předpokládají se rozhraní, dědičnost ne)? V Go to jde částečně přes typové aliasy, jen se pak vyžaduje explicitní přetypováváni, což zbytečně prodlužuje a znepřehledňuje kód. Swift by se mohl dostat blízko, až zavedou plánovaný operátor ~=, ale ten zas mimo macOS/iOS není moc schůdný (verze pro Linux zatím hapruje).
P.S. Dynamické jazyky tento problém nemají, proto jsou v kontextu této diskuze irelevantní.
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.
-
Zdravím, mám konkrétní otázku, ale nejdřív motivace. Všichni mají plnou hubu keců o DRY, KISS, LSP apod., ale když přijde na rozumnou implementaci, jazyky jen hážou klacky od nohy. Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj). Takže - jak řešíte generický ad hoc polymorfismus v OO jazyce bez typových tříd (beru OO obecně, předpokládají se rozhraní, dědičnost ne)? V Go to jde částečně přes typové aliasy, jen se pak vyžaduje explicitní přetypováváni, což zbytečně prodlužuje a znepřehledňuje kód. Swift by se mohl dostat blízko, až zavedou plánovaný operátor ~=, ale ten zas mimo macOS/iOS není moc schůdný (verze pro Linux zatím hapruje).
P.S. Dynamické jazyky tento problém nemají, proto jsou v kontextu této diskuze irelevantní.
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.
Však na GOTO taky není nic špatného (dokud ho nedostane do ruky opice).
-
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.
Však na GOTO taky není nic špatného (dokud ho nedostane do ruky opice).
Myslim, ze takych ludi nebudu trapit ani tie typove triedy.
-
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.
Však na GOTO taky není nic špatného (dokud ho nedostane do ruky opice).
Myslim, ze takych ludi nebudu trapit ani tie typove triedy.
Problém je, že pokud je někdo nadprůměrně dobrý/vzdělaný a umí použít třeba ty typové třídy tak, aby mu tu usnadnilo práci a výsledkem byl lepší kód, tak to prostě v mnohých jazycích nejde - to jsou ty klacky pod nohy. Je jasné, že když někdo lepí kód ze stackoverflow nebo dělá podobné jirsákoviny, tak mu je nějaká typová třída k ničemu.
-
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html (http://www.antonis.de/qbebooks/gwbasman/onerror.html)
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
Popravdě, zrovna toto je strukturovanější přístup, než například v céčku s návratovými kódy a jejich (ne)testováním :-) ERR+ERL jsou vlastně taková poor man alternativa k objektu Exception a vůbec, já na BASICu vyrost (Atari Basic + geniální Turbo Basic). Takže i ten robot jim asi chodil :-)
Mně zas připadá, že tzv. strukturované výjimky a všechny možné variace na toto téma jsou spíš nabourání strukturovaného přístupu. Někomu se kdysi zdálo, že testování chybových stavů znepřehledňuje kód. Že chyby jsou cosi druhořadého, trpěného vedle "hlavního" algoritmu. Podle mě je však chybový stav zcela normální situace, je to prostě jeden z mnoha stavů ve stavovém diagramu a tak by se s ním mělo také zacházet, tj. úplně normálně, jako s každým jiným stavem.
Všelijaké ty trapy apod. akorát vytvářejí paralelní strukturu pro chyby, která pak v praxi ale nekopíruje strukturu "hlavního algoritmu". 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. Korektní zpracování chyby tímto stylem totiž totálně znepřehlední program, daleko víc než prosté testování návratové hodnoty. 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, u pečlivějších se dokonce ví, kde, ale v místě toho "trapu" už se na ni stejně nedá účinně reagovat.
-
Ono je to v podstatě přerušení, a místo GOTO tam jde použít i GOSUB, navíc to proběhne několikanásobně rychleji než nějaké testování přímo v basicovém kódu, takže ve své době to byl určitě pokrok.
Přehlednosti to určitě nepřidá, ale když si promítneš jak vypadal běžný kód s číslovanými řádky v době kdy se to objevilo, tak to už fakt nic zhoršit nemohlo ;D
-
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.
-
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?
-
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.
-
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?
-
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 ;D
-
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.
-
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.
-
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...
-
Výjimky tam jsou.
Kde/jaky?
panic/recover (jen jinak pojmenované výjimky)
-
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.
-
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.
-
chyby se ošetřují blízko vzniku
Což se dá dělat i s výjimkami, takže to není argument.
-
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.
-
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ší").
-
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.
-
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.
-
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.
-
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.
Toto je přístup tvůrce softwaru pro jaderné elektrárny nebo sondu, co má přistát na kometě. Dobře, trochu přeháním... Ono to je v podstatě metodicky správné a kdyby bylo bezprostřední ošetření chyby na jeden řádek, tak by to bylo ideální. Problémem v Go je to nešťastné gofmt, které z každého "if err!=nil{return nil,err}" udělá tři řádky.
-
Toto je přístup tvůrce softwaru pro jaderné elektrárny nebo sondu, co má přistát na kometě. Dobře, trochu přeháním... Ono to je v podstatě metodicky správné a kdyby bylo bezprostřední ošetření chyby na jeden řádek, tak by to bylo ideální. Problémem v Go je to nešťastné gofmt, které z každého "if err!=nil{return nil,err}" udělá tři řádky.
To, že většina používá explicitní "if err!=nil{return nil,err}" neznamená, že je to vždy jediná možnost. Doporučuji se podívat třeba na package bufio a scanner.Err().
jsou to dvě strany téže mince.
Co? Co je jedna strana a co druhá? A jaké jedné mince?
Až doteď jsem si myslel, že ti to pálí trochu víc... ;)
-
Toto je přístup tvůrce softwaru pro jaderné elektrárny nebo sondu, co má přistát na kometě. Dobře, trochu přeháním... Ono to je v podstatě metodicky správné a kdyby bylo bezprostřední ošetření chyby na jeden řádek, tak by to bylo ideální. Problémem v Go je to nešťastné gofmt, které z každého "if err!=nil{return nil,err}" udělá tři řádky.
Ale vy oba pletete hrušky s jabkama. Výjimky umožňují reagovat na chybu v nějakém *bloku*. Tj. je mi jedno, na jakém řádku v bloku k chybě X došlo, prostě blok jako celek selhal kvůli X a reaguju na to způsobem Y. Výjimky slouží k tomu, abych nemusel Y opakovat po každém řádku v bloku. Se spolehlivostí to nemá co dělat.
-
Až doteď jsem si myslel, že ti to pálí trochu víc... ;)
Pálí a nepálí jsou dvě strany téže mince, takže ses nespletl.
-
Toto je přístup tvůrce softwaru pro jaderné elektrárny nebo sondu, co má přistát na kometě. Dobře, trochu přeháním... Ono to je v podstatě metodicky správné a kdyby bylo bezprostřední ošetření chyby na jeden řádek, tak by to bylo ideální. Problémem v Go je to nešťastné gofmt, které z každého "if err!=nil{return nil,err}" udělá tři řádky.
Ale vy oba pletete hrušky s jabkama. Výjimky umožňují reagovat na chybu v nějakém *bloku*. Tj. je mi jedno, na jakém řádku v bloku k chybě X došlo, prostě blok jako celek selhal kvůli X a reaguju na to způsobem Y. Výjimky slouží k tomu, abych nemusel Y opakovat po každém řádku v bloku. Se spolehlivostí to nemá co dělat.
To jsou ty dvě strany mince - buďto mám kód, který jednoznačně handluje chyby - příkaz po příkazu (bude delší, ale názorný) nebo používám výjimky, kde handlování může (a nemusí) být daleko od vzniku. V GO je víc rozlišeno jestli se jedná o chybu, kterou lze ošetřit nebo výjimku, u které autor předpokládal, že dál v procesu nejde pokračovat - např. došla paměť, atd.
-
Toto je přístup tvůrce softwaru pro jaderné elektrárny nebo sondu, co má přistát na kometě. Dobře, trochu přeháním...
Sice je náhodou pravda, že na řídících systémech JE jsem se učil, ale platí to IMHO pro většinu provozů - ať už se řídí reaktor, nebo granulační kotel či ethylenová jednotka. Ve všech případech bude nespolehlivý software příčinou škod.
Se spolehlivostí to nemá co dělat.
Ano i ne. Prvoplánově výjimky spolehlivost zvyšují, protože garantují, že každá chyba někam spadne. Jenže tu zároveň vzniká hned několik nových problémů.
* delokalizovaná chyba se špatně řeší; není to přímo problém samotných výjimek, ale jejich přístup programátory nemotivuje k lokalizaci chyby; čím výše chyba propadne, s tím větším kanónem se pak na ni jde
* problém nedefinovaných stavů, typicky nedokončená inicializace/likvidace; u jazyků s GC je tento problém méně palčivý, ale i tam existuje a o to může být zákeřnější; výjimky de facto násobí počet možných stavů programu a to považuji za velké zlo
* problém optimalizace; mechanismus výjimek redundantně testuje chyby i v místech, kde z principu být nemohou, např. protože už dané hodnoty byly otestovány jinde; to mimo jiné vede k doporučením psát "exception-driven" stylem, kdy např. pole procházíš hlava-nehlava, dokud nevyletí cosi jako array index out of bounds, takže vedle opravdových chybových stavů si vytváříš a testuješ ještě umělé chybové stavy a výsledná změť try-catchů zatemňuje algoritmus mnohem efektivněji než klasické testování návratových hodnot.
-
není to přímo problém samotných výjimek, ale jejich přístup programátory nemotivuje k lokalizaci chyby; čím výše chyba propadne, s tím větším kanónem se pak na ni jde
No, tak jsme se dostali k tomu, co jsem říkal: ve výjimkách problém není - pokud je to potřeba, dají se používat se stejnou granularitou jako návratové kódy.
V Erlangu se výjimky používají a těžko bysme hledali něco, co je víc synonymem pro robustnost než Erlang.
-
není to přímo problém samotných výjimek, ale jejich přístup programátory nemotivuje k lokalizaci chyby; čím výše chyba propadne, s tím větším kanónem se pak na ni jde
No, tak jsme se dostali k tomu, co jsem říkal: ve výjimkách problém není - pokud je to potřeba, dají se používat se stejnou granularitou jako návratové kódy.
V Erlangu se výjimky používají a těžko bysme hledali něco, co je víc synonymem pro robustnost než Erlang.
Otázka je, jestli to není spíš dáno těmi pěti programátory, kteří jediní v Erlangu programují. :D
Ale vážně, pokud bychom hledali absolutní synonymum spolehlivosti, pak by to byl asi TeX. A ačkoliv spolehlivost je určitě dána i povahou a vlastnostmi jazyka (tady konkrétně WEB/CWEB), mnohem víc ji ovlivňuje to, že v něm programují pouze experti, podobně jako v tom Erlangu.
-
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.
Používá se to pro uklízení gorutin, když 3rd party kód zpanikaří (třeba na blbém out of index, nepřípustném přetypování nebo něco takového), runtime zlikviduje tuto jednu padlou gorutinu a jde-li třeba o obsluhu http požadavku, musí knihovna po sobě uklidit.
-
není to přímo problém samotných výjimek, ale jejich přístup programátory nemotivuje k lokalizaci chyby; čím výše chyba propadne, s tím větším kanónem se pak na ni jde
V Erlangu se výjimky používají a těžko bysme hledali něco, co je víc synonymem pro robustnost než Erlang.
Zbytocne tu nedrazdite ludi. Neni kazdy ready na Erlangove "let it crash" a kontrolovany damage mode skrz hierarchiu supervisor actorov.
-
Pokud to neni prilis mimo tema, byl bych zvedavy na vase nazory ohledne vyjimek v C++. Zatim byla diskuze hodne dobra, tak snad to nezazdim.
Specificita
Definujete si vlastni vyjimky nebo hazite vyjimky z STL? Vytvarite pripadne rozsahle hierarchie s konkretni chybou staticky vazanou na typ vyjimky nebo to resite na urovni dat hozene instance?
Modularita systemu
Sveho casu jsem byl ovlivnen C++ FAQ od Marshalla Cline, ktery kazal mit vyjimky definovane spolecne pro cely system bez ohledu na rozhrani a moduly. Dnes uz si tim nejsem tak jist.
https://isocpp.org/wiki/faq/exceptions#mindset-for-proper-use-of-eh
Exception classes cross subsystem boundaries — they are part of the intellectual glue that holds the architecture together.
Delate to stejne nebo mate na kazdem rozhrani definovane vyjimky a v implementaci prekladate?
-
Pokud to neni prilis mimo tema, byl bych zvedavy na vase nazory ohledne vyjimek v C++. Zatim byla diskuze hodne dobra, tak snad to nezazdim.
Specificita
Definujete si vlastni vyjimky nebo hazite vyjimky z STL? Vytvarite pripadne rozsahle hierarchie s konkretni chybou staticky vazanou na typ vyjimky nebo to resite na urovni dat hozene instance?
Modularita systemu
Sveho casu jsem byl ovlivnen C++ FAQ od Marshalla Cline, ktery kazal mit vyjimky definovane spolecne pro cely system bez ohledu na rozhrani a moduly. Dnes uz si tim nejsem tak jist.
https://isocpp.org/wiki/faq/exceptions#mindset-for-proper-use-of-eh
Exception classes cross subsystem boundaries — they are part of the intellectual glue that holds the architecture together.
Delate to stejne nebo mate na kazdem rozhrani definovane vyjimky a v implementaci prekladate?
Není-li nezbytné poskytnout nějaký specifický kontext, je pohodlnější házet výjimky z STL.
-
Velice děkuji všem řečníkům za tenhle rozbor "výjimek". Je to hrozně stará vesta, ale mému hovězímu mozku výjimky dlouhodobě "tak nějak nevyhovují" a nedocházejí. Teď dokážu ten pocit asi i definovat: vadí mi samotný princip, že se snažím oddělit místo zjištění chyby od místa, kde se na ni snažím nějak smysluplně reagovat. V mém přízemním pojetí místo zjištění chyby poskytuje maximum kontextu, potřebného k nějaké smysluplné reakci na vyskytnuvší se chybu. Mohu to zkusit znova, mohu si učinit specifickou poznámku pro nějaké následné zpracování, mohu inteligentně uklidit a nahlásit nějakou mírně abstrahovanou informaci o úroveň výš apod. Jasně, toto lze i s použitím výjimek. Jako výhoda výjimek bývá uváděna čistota kódu, nezapraseného ustavičným lokálním ošetřováním chybových stavů. Nojo, ale když ty chybové stavy řeším pak někde o kus dál všechny na jedné hromadě, oddělené od kontextu jejich vzniku, to má být přehledné a pochopitelné?
Mám pocit, že ať už to člověk píše "postaru" nebo s výjimkami, nakonec je to hlavně o sebekázni a pečlivosti - jak vysoko (daleko od místa vzniku) chybu zachytit a řešit, jak podrobně předem počítat s možností výskytu různých druhů chyb, jak moc "defenzivně" je vhodné programovat apod.
-
Nojo, ale když ty chybové stavy řeším pak někde o kus dál všechny na jedné hromadě, oddělené od kontextu jejich vzniku, to má být přehledné a pochopitelné?
Tohle ale není moc dobrý příklad použití výjimek. Když použijete výjimky správně, budete výjimku pořád ošetřovat v místě jejího vzniku, kde znáte kontext, a pokud se nepodaří ji na daném místě vyřešit, pošlete dál nějakou obecnější výjimku.
Tím „nezaprasením kódu lokálním ošetřování chybových stavů“ se nemyslí to, že se v celé aplikaci nebudete o výjimky zajímat a ošetříte je všechny najednou někde v main. Tím se myslí to, že nemusíte kontrolovat chybový stav po provedení každé jednotlivé funkce a nemusíte na to reagovat pořád dokola tím stejným kódem.
Třeba když chcete otevřít soubor, něco z něj přečíst a soubor zavřít – může dojít ke spoustě výjimečných situací, např. může být soubor v každém kroku nedostupný (např. root odmountuje zařízení, na kterém soubor leží). Nevidím žádnou výhodu v tom ošetřovat tenhle stav znovu po každém z těch třech kroků, protože nezáleží na tom, ve kterém kroku k té chybě došlo, reakce bude pořád stejná.
-
Velice děkuji všem řečníkům za tenhle rozbor "výjimek". Je to hrozně stará vesta, ale mému hovězímu mozku výjimky dlouhodobě "tak nějak nevyhovují" a nedocházejí. Teď dokážu ten pocit asi i definovat: vadí mi samotný princip, že se snažím oddělit místo zjištění chyby od místa, kde se na ni snažím nějak smysluplně reagovat. V mém přízemním pojetí místo zjištění chyby poskytuje maximum kontextu, potřebného k nějaké smysluplné reakci na vyskytnuvší se chybu. Mohu to zkusit znova, mohu si učinit specifickou poznámku pro nějaké následné zpracování, mohu inteligentně uklidit a nahlásit nějakou mírně abstrahovanou informaci o úroveň výš apod. Jasně, toto lze i s použitím výjimek. Jako výhoda výjimek bývá uváděna čistota kódu, nezapraseného ustavičným lokálním ošetřováním chybových stavů. Nojo, ale když ty chybové stavy řeším pak někde o kus dál všechny na jedné hromadě, oddělené od kontextu jejich vzniku, to má být přehledné a pochopitelné?
Mám pocit, že ať už to člověk píše "postaru" nebo s výjimkami, nakonec je to hlavně o sebekázni a pečlivosti - jak vysoko (daleko od místa vzniku) chybu zachytit a řešit, jak podrobně předem počítat s možností výskytu různých druhů chyb, jak moc "defenzivně" je vhodné programovat apod.
Výhoda výjimek je jen v tom, že umožňují "long jump". Nevýhoda je v tom, že jdou zneužít k simulaci longjmp. Nejlépe má výjimky udělané Swift, i když v knihovně to s nimi trochu přehnali.
-
Tohle ale není moc dobrý příklad použití výjimek. Když použijete výjimky správně, budete výjimku pořád ošetřovat v místě jejího vzniku, kde znáte kontext, a pokud se nepodaří ji na daném místě vyřešit, pošlete dál nějakou obecnější výjimku.
A taky je výhoda v tom, že člověk může na nějakém místě ošetřit jenom určitou třídu výjimek (např. ty souborové chyby) a ostatní pustit na vyšší vrstvu - přičemž je hnedka z kódu jasné, co pouští dál (třeba u Javy úplně explicitně). To se sice dá s návratovými kódy taky simulovat, ale je to krkolomnější, málo explicitní a většina jazyků neumí zkontrolovat, že bylo ošetřeno opravdu všechno, co může nastat (pokrytí celého výčtového typu kontrolují většinou jenom funkcionální jazyky).
-
Krome navratovych hodnot a vyjimek existuje jeste treti bezny mechanismus osetrovani chybovych stavu - error handlery. To ma treba Common Lisp ve forme signalu. (Bohuzel, moje oblibena kniha Code Complete na tenhle treti zpusob zapomina, za coz puvodne asi muze dost omezena implementace signal handleru v Unixu, ktera zpusobila, ze v C-like jazycich tato metoda neni prilis popularni.)
Z hlediska programatora jede v podstate vzdy o kompromis mezi temito tremi mechanismy. Vyjimky jsou lepsi nez navratove hodnoty, protoze umoznuji osetrit chybu na libovolne urovni. Error handlery jsou lepsi nez vyjimky, protoze neodvinou zasobnik a lokalni promenne. Navratove hodnoty jsou lepsi nez error handlery, protoze jsou podstatne jednodussi na pouzivani.
Ve funkcionalnim programovani se ty tri moznosti trochu stiraji do jednoho zpusobu (chyba jako navratova hodnota), protoze obvykle maji dostatecne moznosti abstrakce, takze umoznuji tak nejak emulovat vyhody ostatnich zpusobu.
-
Error handlery jsou lepsi nez vyjimky, protoze neodvinou zasobnik a lokalni promenne.
Tohle ale neplatí ve všech programovacích jazycích! Víme? Ne všude se odvíjí celý zásobník, a můžeme tedy pokračovat i od místa, kde výjimka vznikla. O čemž si ta zbývající většina programovacích jazyků může nechat jen zdát.
-
Error handlery jsou lepsi nez vyjimky, protoze neodvinou zasobnik a lokalni promenne.
Tohle ale neplatí ve všech programovacích jazycích! Víme? Ne všude se odvíjí celý zásobník, a můžeme tedy pokračovat i od místa, kde výjimka vznikla. O čemž si ta zbývající většina programovacích jazyků může nechat jen zdát.
Ano, vime, tomu se rika error handler, a napsal jsem o tom predchozi prispevek. ;-)
-
Error handlery jsou lepsi nez vyjimky, protoze neodvinou zasobnik a lokalni promenne.
Tohle ale neplatí ve všech programovacích jazycích! Víme? Ne všude se odvíjí celý zásobník, a můžeme tedy pokračovat i od místa, kde výjimka vznikla. O čemž si ta zbývající většina programovacích jazyků může nechat jen zdát.
Ano, vime, tomu se rika error handler, a napsal jsem o tom predchozi prispevek. ;-)
Dobře dobře, asi jsme si nerozumněli. Stejně tak by se dalo říct, že: error handler je VŽDY to místo kde se ošetřuje výjimka, ale co se děje se zásobníkem je věc jiná, a to je různé.
-
Error handlery jsou lepsi nez vyjimky, protoze neodvinou zasobnik a lokalni promenne.
Tohle ale neplatí ve všech programovacích jazycích! Víme? Ne všude se odvíjí celý zásobník, a můžeme tedy pokračovat i od místa, kde výjimka vznikla. O čemž si ta zbývající většina programovacích jazyků může nechat jen zdát.
Ano, vime, tomu se rika error handler, a napsal jsem o tom predchozi prispevek. ;-)
Dobře dobře, asi jsme si nerozumněli. Stejně tak by se dalo říct, že: error handler je VŽDY to místo kde se ošetřuje výjimka, ale co se děje se zásobníkem je věc jiná, a to je různé.
Nedalo by se to rict - error handler je rutina, ktera se vola, ne misto ve zdrojaku. A protoze je to rutina, ktera se vola, se zasobnikem (a tedy lokalnimi promennymi) se nic nedeje.
Aspon tak to funguje na te nejnizsi urovni, a na te nejnizsi urovni jsou skutecne tyto tri moznosti, jak se vyporadat s chybami. Muzes to samozrejme ruzne abstrahovat (jak to delaji treba funkcionalni jazyky, nebo dalsi jazyky, ktere abstrahuji samotny koncept zasobniku), ale to jen znamena, ze si s tim za tebe nejak poradi prekladac a vyuzije jednu z tech tri moznosti.
-
Nedalo by se to rict - error handler je rutina, ktera se vola, ne misto ve zdrojaku. A protoze je to rutina, ktera se vola, se zasobnikem (a tedy lokalnimi promennymi) se nic nedeje.
Pokud to tedy není totéž, jako "exception handler", který si napíšu do zdrojáku, tak se ptám, jestli je to totéž, jako když vyhodím výjimku, která se zásobníkem také "nic nedělá"(?) A když se to jmenuje error handler, je to použitelné pouze pro chyby, nebo tím můžu signalizovat vyšší vrstvě třeba i průběh nějaké operace?
Potom by se to mělo jmenovat asi jinak.
-
Nedalo by se to rict - error handler je rutina, ktera se vola, ne misto ve zdrojaku. A protoze je to rutina, ktera se vola, se zasobnikem (a tedy lokalnimi promennymi) se nic nedeje.
Pokud to tedy není totéž, jako "exception handler", který si napíšu do zdrojáku, tak se ptám, jestli je to totéž, jako když vyhodím výjimku, která se zásobníkem také "nic nedělá"(?) A když se to jmenuje error handler, je to použitelné pouze pro chyby, nebo tím můžu signalizovat vyšší vrstvě třeba i průběh nějaké operace?
Potom by se to mělo jmenovat asi jinak.
O jakem jazyce mluvis, prosim te? Ano, nektere jazyky umoznuji definovat error handler ve zdrojaku, treba Common Lisp (nebo PL/I).
Podstatne je, ze to o cem mluvim, jsou tri zakladni zpusoby implementace osetreni chyb. Moznosti konkretniho jazyka pak mohou tem implementacim bud primo odpovidat, nebo od nich byt nejak abstrahovany. V jazycich nizsi urovne (tedy tak zhruba po Javu/C# vcetne) to vicemene primo odpovida.
-
Nedalo by se to rict - error handler je rutina, ktera se vola, ne misto ve zdrojaku. A protoze je to rutina, ktera se vola, se zasobnikem (a tedy lokalnimi promennymi) se nic nedeje.
Pokud to tedy není totéž, jako "exception handler", který si napíšu do zdrojáku, tak se ptám, jestli je to totéž, jako když vyhodím výjimku, která se zásobníkem také "nic nedělá"(?) A když se to jmenuje error handler, je to použitelné pouze pro chyby, nebo tím můžu signalizovat vyšší vrstvě třeba i průběh nějaké operace?
Potom by se to mělo jmenovat asi jinak.
Když on je ty a ty jsi on a ty jsi ty, jsem já furt já? Kdo jí tohle kuře, co? Co se to sakra děje??
-
Nedalo by se to rict - error handler je rutina, ktera se vola, ne misto ve zdrojaku. A protoze je to rutina, ktera se vola, se zasobnikem (a tedy lokalnimi promennymi) se nic nedeje.
Pokud to tedy není totéž, jako "exception handler", který si napíšu do zdrojáku, tak se ptám, jestli je to totéž, jako když vyhodím výjimku, která se zásobníkem také "nic nedělá"(?) A když se to jmenuje error handler, je to použitelné pouze pro chyby, nebo tím můžu signalizovat vyšší vrstvě třeba i průběh nějaké operace?
Potom by se to mělo jmenovat asi jinak.
O jakem jazyce mluvis, prosim te? Ano, nektere jazyky umoznuji definovat error handler ve zdrojaku, treba Common Lisp (nebo PL/I).
Podstatne je, ze to o cem mluvim, jsou tri zakladni zpusoby implementace osetreni chyb. Moznosti konkretniho jazyka pak mohou tem implementacim bud primo odpovidat, nebo od nich byt nejak abstrahovany. V jazycich nizsi urovne (tedy tak zhruba po Javu/C# vcetne) to vicemene primo odpovida.
Pro Lisp a Výjimky platí toto:
Transfer of Control to an Exit Point:
1) Intervening exit points are abandoned
...
Zdroj: http://www.lispworks.com/documentation/HyperSpec/Body/05_b.htm
In Common Lisp, there are functions throw and catch, but these are not related to the condition system.
Zdroj: https://rosettacode.org/wiki/Exceptions#Common_Lisp
Takže ano, error handler v Lispu je něco jiného než Výjimky. Ale říkají tomu jinak.
Už jsem si málem myslel, že to Lisp umí taky, ale neumí. Smalltalk to výjimkami umí - pokračovat tam, kde kde byla výjimka signalizována.
-
Takže ano, error handler v Lispu je něco jiného než Výjimky. Ale říkají tomu jinak.
Ne uplne jinak - mas signal a k nemu error handler. Tahle terminologie pokud vim pochazi z operacnich systemu a saha minimalne nekam do zacatku 60. let. Ostatne muzes to videt i na Unixu, kde je bohuzel ta myslenka dost omezena (pouzitelnych signalu je jen hrstka). A z toho vyplyva neznalost te koncepce u Cckaru a Javistu.
Už jsem si málem myslel, že to Lisp umí taky, ale neumí. Smalltalk to výjimkami umí - pokračovat tam, kde kde byla výjimka signalizována.
To je mozne, Smalltalk neznam, ale rekl bych, ze v takovem pripade ten rozdil nedava moc smysl, protoze implementace Smalltalku nema nutne zasobnik. Ale vyjimky se treba sveho casu v C++ (a jak koukam do Wikipedie, tak asi i v Lispu, z ktereho ten koncept pochazi) implementovaly primo zmenou prislusneho ramce zasobniku.
Jelikoz je Lisp pomerne nizkourovnovy, tak ma jak vyjimky, tak signaly. (A k tomu samozrejme i vraceni navratovych hodnot - dokonce vice nez jedne.)