Jak můžu opustit funkci

[Kit]

Nevím jak obecně u funkcionálních, ale v Haskellu mám radši stráže a vzory než if/else

Stráže a vzory se mi také líbí. Princip je podobný ACL.

[Reklama]

[ded.kenedy]

Ale vždyť toto je blbost. Proč by nemohl mít return v ifu?

Bylo by vhodne naucit se vnimat veci v kontextu a ne jen jednotlive drobne useky. Vzdyt pisu:

hned ve druhem prispevku (a byl to vlastne duvod dotazu jako takoveho) jde videt, k cemu muze nedomyslene predcasne opusteni funkce returnem vest, tj. resource leaky, nedefinovane stavy, visici zamky...

[Cikáda]

Ale vždyť toto je blbost. Proč by nemohl mít return v ifu?

Bylo by vhodne naucit se vnimat veci v kontextu a ne jen jednotlive drobne useky. Vzdyt pisu:

hned ve druhem prispevku (a byl to vlastne duvod dotazu jako takoveho) jde videt, k cemu muze nedomyslene predcasne opusteni funkce returnem vest, tj. resource leaky, nedefinovane stavy, visici zamky...

Úplně nejlepší by bylo být schopen psát a strukturovat text tak, aby dával ten smysl, co chci. Nebo to máme chápat tak (pokud na sebe odstavce navazují), že if s returnem je "nedomyšlené předčasné opuštění funkce"?

[ded.kenedy]

pokud na sebe odstavce navazují

Ano, navazuji, proto byly v puvodnim prispevku uvedeny za sebou.

Nebo to máme chápat tak, že if s returnem je "nedomyšlené předčasné opuštění funkce"?

Ne, nemate. Vsimnete si, ze v dane vete bylo pouzito modalni sloveso "muze". Z toho plyne, ze ne kazde pouziti if s returnem je nedomyslene, ale pokud je, ma to opravdu neprijemne dusledky. A z vlastni zkusenosti muzu rict, ze zacinajici programatori opravdu maji problemy dusledky takoveho "vyskoceni" domyslet. Proto je lepsi, kdyz se takovym konstrukcim budou vyhybat, obzvlast, pokud maji problem zvladnout jazyk jako takovy.

[Kit]

Nebo to máme chápat tak, že if s returnem je "nedomyšlené předčasné opuštění funkce"?

Ne, nemate. Vsimnete si, ze v dane vete bylo pouzito modalni sloveso "muze". Z toho plyne, ze ne kazde pouziti if s returnem je nedomyslene, ale pokud je, ma to opravdu neprijemne dusledky. A z vlastni zkusenosti muzu rict, ze zacinajici programatori opravdu maji problemy dusledky takoveho "vyskoceni" domyslet. Proto je lepsi, kdyz se takovym konstrukcim budou vyhybat, obzvlast, pokud maji problem zvladnout jazyk jako takovy.

Začátečník se takovým situacím nemá učit vyhýbat, ale má se je učit zvládat. Minimálně 90 % funkcí nemá v takové situaci alokované žádné prostředky, nemusí je tedy uvolňovat a může rovnou skončit returnem. Takové funkce tedy není nutné prznit nějakým dogmatem o jednom výstupním bodu.

[Reklama]

[Cikáda]

pokud na sebe odstavce navazují

Ano, navazuji, proto byly v puvodnim prispevku uvedeny za sebou.

To je podmínka nutná, ale ne postačující.

Nebo to máme chápat tak, že if s returnem je "nedomyšlené předčasné opuštění funkce"?

Ne, nemate. Vsimnete si, ze v dane vete bylo pouzito modalni sloveso "muze". Z toho plyne, ze ne kazde pouziti if s returnem je nedomyslene, ale pokud je, ma to opravdu neprijemne dusledky.

Výborně, takže blbost je jen ta první část, jak jsem to bral původně.

Podívejme se na to:

(...) k hezkemu strukturovanemu programovani return v if-u nepatri, a pokud mam nekde if, melo byt mit i else (...)

a

(...)

Bylo by vhodne naucit se vnimat veci v kontextu a ne jen jednotlive drobne useky. Vzdyt pisu:

hned ve druhem prispevku (a byl to vlastne duvod dotazu jako takoveho) jde videt, k cemu muze nedomyslene predcasne opusteni funkce returnem vest, tj. resource leaky, nedefinovane stavy, visici zamky...

Takže obecné (mylné) tvrzení obhajujeme "modálním slovesem může", respektive nějakým hypotetickým "nedomyšleným řešením", které může, ale nemusí nastat. (proto jsem se tak "hloupě ptal", zdali na sebe navazují, protože takto vedle sebe je ta blbost, co jsi napsal, vidět jasně)
Tak tu poznámku s kontextem si příště nechej od cesty a napiš to líp.

--------------------------------------

A z vlastni zkusenosti muzu rict, ze zacinajici programatori opravdu maji problemy dusledky takoveho "vyskoceni" domyslet. Proto je lepsi, kdyz se takovym konstrukcim budou vyhybat, obzvlast, pokud maji problem zvladnout jazyk jako takovy.

Tento přístup chápu, ale nepovažuji jej za správný. Zvlášť pokud člověk začíná s programováním, tak takto černobílé vyhýbání se relativně základním konceptům vede ke špatným návykům. Naopak by bylo fajn si s takovým člověkem "sednout" a vysvětlit mu v čem by mohl být problém. Tento přístup má i tu výhodu, že se začne na svůj kód dívat zase trošku jinak. Ale ne vždycky je to možné


@Kit - tady plně souhlasím

[balki]

Vas  tu este stale bavi tu jednu moju vetu rozoberat a negovat? Vysoka skola zivota tato diskusia. (Bolo to myslene pejorativne)

[Cikáda]

A uz slubujem, ze v tomto topicu na nic nereagujem, nech si napise kto chce, co che. Nepotrebujem krmit trollov. (Nemyslim konkretne vas)

[Kit]

TDD je frikulinsky agilny vymysel poslednych rokov, aby sme mali na co pri robote nadavat.  Ale budis, asi jo, v nejakej inej forme sa to tam asi robi.

TDD používám už asi 20 let. Jenom se tomu tenkrát tak neříkalo. Podobně provozuji Scrum déle, než existuje tento pojem. Pouze se mezitím našel někdo, kdo sepsal pravidla a dal tomu jméno.

[Kiwi]

Výjimky jsou zlo. C++ je zlo.

http://250bpm.com/blog:4
http://250bpm.com/blog:8

Koukám, že výjimky v C++ jsou skutečně zlo, zejména když je někdo použije tak hloupým způsobem, jako autor těch článků.

Mně taky nikdy nesedly. Nikdo nikdy mi nedokázal smysluplně vysvětlit, jaký je rozdíl mezi stavem a chybovým stavem a proč bych to druhé měl v programu řešit nějakými úplně jinými konstrukcemi a postupy a na jiných místech než to první.

[Kit]

Koukám, že výjimky v C++ jsou skutečně zlo, zejména když je někdo použije tak hloupým způsobem, jako autor těch článků.

Mně taky nikdy nesedly. Nikdo nikdy mi nedokázal smysluplně vysvětlit, jaký je rozdíl mezi stavem a chybovým stavem a proč bych to druhé měl v programu řešit nějakými úplně jinými konstrukcemi a postupy a na jiných místech než to první.

Celková koncepce je postavená na tom, že každá komponenta (aplikace, objekt, metoda) má jeden vstup, jeden výstup a jeden chybový výstup. Vstupy se předávají přes parametry, výstupy jsou obecně objekty a chybovými výstupy chybové objekty, tedy výjimky. Pro každou z těchto tří kategorií jsou samostatné konstrukty - stačí je jen používat.

Při důsledném používání výjimek jsou stavy nepotřebné. Funkce vrací hodnotu. Procedura něco dělá, ale návratová hodnota je void. Místo chybových stavů se v obou případech použijí výjimky, které ten chybový stav popisují mnohem lépe, než pouhý návratový kód.

[Cikáda]

(...)

Při důsledném používání výjimek jsou stavy nepotřebné. Funkce vrací hodnotu. Procedura něco dělá, ale návratová hodnota je void. Místo chybových stavů se v obou případech použijí výjimky, které ten chybový stav popisují mnohem lépe, než pouhý návratový kód.

Lze to i otočit - při důsledném používání stavů jsou výjimky nepotřebné. Tím nechci říct, že výjimky jsou k ničemu, jen mi zrovna toto nepřijde jako ultimátní argument. Chybový stav může popsat návratový stav stejně dobře jako výjimka, jde jen o to udělat v tom systém, respektive "udělat dokumentaci".
Ve výsledku je třeba ošetřit obojí - při použití výjimek vyřešit "chybu" a případně nahradit návratovou hodnotu nějakou smyslupnou - při použití návratových kódů je opět třeba to stejné. Upřímně moc ten rozdíl nevidím, jen se výrazně liší syntax, která je imho o kus komplikovanější. Nutno ale dodat, že nejvíce mám naprogramováno v Céčku a Haskellu, kdy v prvním výjimky úplně nejsou a v druhém jsou de facto jen v IO. Ale toto je asi na trochu jinou diskusi (které se nebráním, ba naopak!), tady jsme trochu OT.

[ded.kenedy]

Začátečník se takovým situacím nemá učit vyhýbat, ale má se je učit zvládat.

Zacatecnik ma obvykle mnohem jine starosti. Vetsinou je rad, ze kod splnuje zadani. Ver mi, v praci delam code review i pro hodne zacinajici programatory.

Minimálně 90 % funkcí nemá v takové situaci alokované žádné prostředky.

A pak je tech zbylych deset procent, kde se na to muze zapomenout a hned mas memory leak nebo neuvolneny zamek raz dva. Pokud pouziji tvuj odhad, tak deseti procentni riziko, ze neco nekde prehlednu je opravdu vysoke a neprijatelne.

Tento přístup chápu, ale nepovažuji jej za správný.

To je tvuj nazor, ale bavime-li se o strukturovanem programovani, tak tam opravdu prikazy skoku (at uz jsou pojmenovany jakkoliv) nepatri, protoze tyto konstrukty rozbiji co? Strukturu kodu!

[balki]

TDD je frikulinsky agilny vymysel poslednych rokov, aby sme mali na co pri robote nadavat.  Ale budis, asi jo, v nejakej inej forme sa to tam asi robi.

TDD používám už asi 20 let. Jenom se tomu tenkrát tak neříkalo. Podobně provozuji Scrum déle, než existuje tento pojem. Pouze se mezitím našel někdo, kdo sepsal pravidla a dal tomu jméno.

Ja som pouzival docker na PMD-85, len to nebol docker a fungovalo to uplne inak.

[Kit]

Při důsledném používání výjimek jsou stavy nepotřebné. Funkce vrací hodnotu. Procedura něco dělá, ale návratová hodnota je void. Místo chybových stavů se v obou případech použijí výjimky, které ten chybový stav popisují mnohem lépe, než pouhý návratový kód.

Lze to i otočit - při důsledném používání stavů jsou výjimky nepotřebné. Tím nechci říct, že výjimky jsou k ničemu, jen mi zrovna toto nepřijde jako ultimátní argument. Chybový stav může popsat návratový stav stejně dobře jako výjimka, jde jen o to udělat v tom systém, respektive "udělat dokumentaci".

Jistě, bývaly doby, kdy se výjimky nepoužívaly a také to fungovalo.

Ve výsledku je třeba ošetřit obojí - při použití výjimek vyřešit "chybu" a případně nahradit návratovou hodnotu nějakou smyslupnou - při použití návratových kódů je opět třeba to stejné. Upřímně moc ten rozdíl nevidím, jen se výrazně liší syntax, která je imho o kus komplikovanější. Nutno ale dodat, že nejvíce mám naprogramováno v Céčku a Haskellu, kdy v prvním výjimky úplně nejsou a v druhém jsou de facto jen v IO. Ale toto je asi na trochu jinou diskusi (které se nebráním, ba naopak!), tady jsme trochu OT.

Pokud z nějaké knihovny obdržím návratový kód, tak ho mohu zpracovat, ale také ignorovat. Když tento kód převedu na výjimku, což zpravidla znamená vytvořit objekt, do kterého se uloží všechny potřebné informace o chybě, tak takový objekt není možné ignorovat. Jinak propadne až ven z aplikace a vypíše se, co bylo příčinou pádu.

Syntaxe je záměrně jiná, výsledek je naopak mnohem jednodušší. Neošetřuje se jednotlivě každá výjimka, ale celá skupina. Není tedy třeba se po každém provedení příkazu ptát, zda proběhl v pořádku, což způsobovalo dlouhé špagety. Místo toho se udělá sekvence příkazů, ve které se výjimky ošetří společně. Není ani potřebné, aby výjimka byla ošetřena v metodě, ve které vznikla - je to spíš nežádoucí právě kvůli zjednodušení.