Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Kit

Stran: 1 ... 33 34 [35] 36 37 ... 47
511
Výjimečné chyby ošetříš o pár pater výš a vhledem k jednotnému rozhraní v tom nevidím žádný problém. Granularitu lze kdykoli zjemnit odchycením výjimky a uložením do stacku nové výjimky na vyšším levelu. Tím si zdroj výjimky krásně vytrasuješ.
Jednotné rozhraní čeho? Neznámou Exception můžu akorát tak převést na neznámý řetězec, ten zalogovat a pak zdechnout. To už můžu zavolat při jakékoliv chybě rovnou abort. V tom crashdumpu ten callstack dostanu taky.

Výjimky nejsou final, klidně si je můžeš podědit a rozšířit o další atributy dle libosti. Při ošetřování jdeš od specializovaných k obecným. Je to velmi jednoduché.

512
Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.

513
Když místo výjimek použiješ návratovou hodnotu, tak musíš použít kolem ní dost bižuterie, aby se ti hodnoty nepomíchaly s chybovými stavy, takže se ceny vyrovnají. Výjimky jsou však výrazně přehlednější, protože jejich ošetření se nachází mimo výkonný kód.

A jako vždy: když neošetříš výjimku, tak se sama ozve. Neošetřený návratový kód bude zticha.
Když neošetříš výjimku, tak se zas tak moc neozve. V lepším případě to v runtime komplet zdechne. V horším případě cestou nahoru rozbije nějaký ten invariant a chytně ji nějaký obecný catch blok.
V novém C++ máme třeba [[nodiscard]], takže neošetřený návratový kód se ozve už při kompilaci.

Zásadní problém výjimek je IMO právě to, že jsou oddělené od výkonného kódu a nejsou vidět.
Při pohledu na cizí kód nevím, co může a nemůže házet. Psát tak, že může házet opravdu cokoliv se moc nedá. Minimálně úklid a nějaký "commit" úspěšně vypočítaných hodnot (v c++ je to třeba oblíbený vzor výpočet a pak noexcept swap) musí jít bez házení. Jinak není moc šance udržet nějaké invarianty, leda tak při chybě všechno zahodit a doufat že to GC zvládne všechno pouklízet. O nějaké "strong exception safety" se v takovém případě moc uvažovat nedá.
Výkonný kód a chyby v něm jsou logicky dost úzce svázané a když je to na dvou místech tak se může snáze stát, že se upraví jen jedno. Ošetření výjimečných chyb je, díky tomu že to nastává jen zřídka, ten nejmíň otestovaný a nejvíc zabugovaný kód.

Z mých zkušeností byly výjimky výhodné, pokud jsem chyby nechtěl řešit. Tak trochu strčit hlavu do písku a nechat ať si to volající přebere. Ve chvíli kdy jsem začal přemýšlet nad možnými chybami a co by se v takovém případě mělo stát byly výjimky dost nešikovné. Právě díky tomu, že jsem ty možné stavy musel rozseknout a řešit na dvou místech.

Tak to máme s výjimkami opačné zkušenosti. Neošetřené výjimky se mi krásně ozývají už v testech a vzhledem k tomu, že mají společného rodiče, vím přesně co může házet. V C++ je to jinak - výjimky mohou být jakéhokoli typu a proto je v tom bordel, který popisuješ. O schopnostech GC nemám pochybnosti.

Výjimečné chyby ošetříš o pár pater výš a vhledem k jednotnému rozhraní v tom nevidím žádný problém. Granularitu lze kdykoli zjemnit odchycením výjimky a uložením do stacku nové výjimky na vyšším levelu. Tím si zdroj výjimky krásně vytrasuješ.

Když upravíš jen kód nebo ošetření výjimek, tak tě na to testy hned upozorní. Toho bych se nebál.

514
Vždy radostu si tu počíst. Někdo slyšel haskellu a hnedka se už považuje za neobyčejného (nebo jaký je opak obyčejného?) vývojaře.  8)
Nechtěl bys to trochu rozvést? Ovládáš snad Haskell lépe než ti, kteří se tu o něm zmiňují? Pochlub se, rád se přiučím.
Diky, ale opravdu se tu s váma (tím myslí, tu zdejší spam "elitu") nechci poměřovat / spamovat. Jen jsem chtěl vypíchnout tu absorditu, jak jinak obyčejní programátoři (všichni tu lepíte nějaký informační systémy a neříkejte, že ne), se dokážou navážet do obyčejných prográmátorů.

Nebýt této komunity, asi bych se o Haskellu nedozvěděl. Snad není špatně, když se jich občas zeptám jak ho používají? Sám používám převážně PHP a XSLT, ale nebráním se rozšiřování obzorů.

V čem tedy programuješ?

515
Zbývají výjimky, které nejsou drahé, jsou praktické a vcelku efektivně brání logickým špagetám (není potřebné "else"). Jen se nesmí zneužívat k flow-controll.

To je zase nepodložených tvrzení. 1) Nezbývají výjimky. 2) Pokud způsobí stack-unwinding, tak ano, jsou typicky významně dražší než návratová hodnota. 3) Nevím, proč by mělo být potřebné else.

Když místo výjimek použiješ návratovou hodnotu, tak musíš použít kolem ní dost bižuterie, aby se ti hodnoty nepomíchaly s chybovými stavy, takže se ceny vyrovnají. Výjimky jsou však výrazně přehlednější, protože jejich ošetření se nachází mimo výkonný kód.

A jako vždy: když neošetříš výjimku, tak se sama ozve. Neošetřený návratový kód bude zticha.

516
Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.
To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.
Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.
Nevím, co na auto [ ] = vypadá nepatřičně.

Blbě se to používá ve výrazech.

517
Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.
To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.

Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.

Referencovaný argument byl zamítnut kvůli side-effectu a jsem téhož názoru.

Zbývají výjimky, které nejsou drahé, jsou praktické a vcelku efektivně brání logickým špagetám (není potřebné "else"). Jen se nesmí zneužívat k flow-controll.

518
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
V Javě jsou zvykem výjimky, dělal bych to tedy výjimkami. Ne proto, že by to byla nějaká zvláštní výhra, ale protože je to tam zvykem.
C++ nedělám, to je hnusnej jazyk.

Je možno si všimnout, že mnoho, zvláště staticky typovaných jazyků, používají návratovou hodnotu. Mnoho dalších jazyků používá výjimky. Šermovat tu s CleanCode a brát výjimky jako písmo svaté je poněkud... nezkušené.

C++ a Java jsou staticky typované? Skaláry možná, ale objekty jsou typované dynamicky.

519
Je snad logické, že se jich ptám, jak by to tedy řešili v C++ a Javě, kdyby nesměli výjimky používat. Nabízí se mi pouze kostrbatá řešení, které buď používají, anebo mají něco lepšího.
Máš selektivní slepotu na Maybe? Vždyť ti to tu píšou furt dokola.

Jak jsem měl poznat, že nemají na mysli Maybe z Haskellu, ale Maybe z C++ a Javy?

520
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
O monádách jsi už slyšel?  ::)
Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.
Tak proč se ptáš?

Přečti si diskuzi. Používám výjimky tam, kde mají být. Někteří diskutující píší, že by se neměly používat, protože jsou drahé, že by se měly používat návratové hodnoty. Z mého pohledu jen s výjimkami neumí pracovat.

Je snad logické, že se jich ptám, jak by to tedy řešili v C++ a Javě, kdyby nesměli výjimky používat. Nabízí se mi pouze kostrbatá řešení, které buď používají, anebo mají něco lepšího.

521
Když budeš ignorovat návratové kódy, tak se ti bude program chovat podivně. S výjimkami se ti to nemůže stát, tedy pokud je nebudeš polykat.
Jakože když budu ignorovat návratové kódy, tak se bude program chovat divně, ale když budu ignorovat výjimky, tak se divně chovat nebude?  :D

Přesně tak. Pokud neodchytíš výjimku, program zhavaruje a vypíše report, proč a kde zhavaroval. To není podivné, ale standardní chování.

Pokud budeš ignorovat návratový kód s chybou, tak s ní pojede dál a ani se nedozvíš, co se stalo, co bylo příčinou podivného chování.

522
Návratová hodnota je určena pro data. Pokud bych například místo stringu dostal int nebo boolean, tak by z toho navazující kód mohl být zmaten. Takovou funkci či metodu by nebylo možné použít ve výrazu. Analýza typu návratové hodnoty je zase code smell.
Pokud místo stringu dostanu int nebo boolean, tak je chyba trochu jinde než ve výjimkách / návratové hodnotě.

Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.

Haskell prosím odlož stranou, bavíme se o objektových jazycích. Golang také můžeš vynechat, jelikož jeho řešení znám. Zajímá mě (a podle nadpisu nejen mne) řešení pro C++ a Javu.

523
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
O monádách jsi už slyšel?  ::)

Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.

524
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.

525
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
To je ještě sranda. Ale jak to uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem a nesmíš vyhazovat výjimky?
V parametrech předám vhodný objekt.
Takže side-effect. To jsme si teda pomohli.

O tom side-effectu vím a proto používám výjimky. Tak se předveď, jak bys to vyřešil.
Jednoduše. Já bych v prvé řadě nevytvářel umělá omezení.

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Návratová hodnota je určena pro data. Pokud bych například místo stringu dostal int nebo boolean, tak by z toho navazující kód mohl být zmaten. Takovou funkci či metodu by nebylo možné použít ve výrazu. Analýza typu návratové hodnoty je zase code smell.

Výjimky to skutečně řeší mnohem lépe a popisněji. Dozvím se z nich nejen návratový kód, ale i co a kde se stalo a za jakých okolností. A když se mi nechce ji zachytávat, tak ji prostě nechám propadnout.

Když budeš ignorovat návratové kódy, tak se ti bude program chovat podivně. S výjimkami se ti to nemůže stát, tedy pokud je nebudeš polykat.

Stran: 1 ... 33 34 [35] 36 37 ... 47