Jak můžu opustit funkci

[Cikáda]

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.

No pokud jim radíš, že po ifu má být vždy else a return do ifu nepatří, tak jim akorát další starosti přidáváš.

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.

To ale @Kit neřekl. Mimo to, kolik začátečníků si hraje se zámky ?

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!

1) Strukturované programování je především o logické struktuře kódu, ne o nějakých pseudopravidlech. Hlavně z mého předchozího příkladu - to by měl být zbytek funkce v else větvi, abys byl spokojen?
2) Mimochodem If/Else mají také za následek skok, tak přemýšlím, jak rozbíjí strukturu kódu.
3) O jaké struktuře kódu mluvíš? Jak ji return v ifu rozbíjí, respektive jak vypadá tvůj main v céčku?

Ano, je to můj názor a zatím jsi nebyl schopen říct, v čem je špatný.

[Reklama]

[Cikáda]

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.

Jistě, pokud používám funkce/knihovnu, kde se výjimky používají, tak pak není na výběr. Spíš mi šlo o to, proč bych měl na návratový kód "kašlat" (tento přístup), respektive vždycky upřednostňovat výjimky. Aspoň takový jsem z tvého vyjádření měl pocit.

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í.

Jistě, to dává smysl. Na stranu druhou když ošetřuji společně výjimky pro sekvenci příkazů, tak poté pravděpodobně ztratím tu "rozlišovací schopnost", co se kde stalo (jistě, ošetřuji třeba podobné/stejné problémy/výjimky, ale už je problém s tím kde, ne? Respektive chci-li řešit toto, tak to do kódu několik řádků přidá, či ne?).
To poslední beru, to je relevantní.

[ded.kenedy]

No pokud jim radíš, že po ifu má být vždy else a return do ifu nepatří, tak jim akorát další starosti přidáváš.

Radim jim, jak kod udelat srozumitelnejsi, aby se v nem oni a lidi, co budou jejich kod cist, vyznali hned napoprve. Ale to neni vec pro frajery, jak jsem psal vcera.

To ale @Kit neřekl.

Ale plyne to z toho.

Mimo to, kolik začátečníků si hraje se zámky ?

Tak si misto zamek dopln: neuzavreny soubor, neuvolnene spojeni do databaze a souvisejici alokovane objekty, neuzavrene sitove spojeni. Opravdu to zacatecnici nepouzivaji?

1) Strukturované programování je především o logické struktuře kódu, ne o nějakých pseudopravidlech.

A te struktury kodu dosahnes jak?

Mimochodem If/Else mají také za následek skok, tak přemýšlím, jak rozbíjí strukturu kódu.

Ja jsem k autistum tolerantni, ale vest s nimi diskuze o nicem me nabavi.

O jaké struktuře kódu mluvíš?

Precti si neco o strukturovanem programovani, bude stacit wikipedie, urcite te to obohati.

[Cikáda]

No pokud jim radíš, že po ifu má být vždy else a return do ifu nepatří, tak jim akorát další starosti přidáváš.

Radim jim, jak kod udelat srozumitelnejsi, aby se v nem oni a lidi, co budou jejich kod cist, vyznali hned napoprve. Ale to neni vec pro frajery, jak jsem psal vcera.

Čitelnost je vždycky důležitá, ale vynucováním blbostí jí akorát tak ublížíš. Viz dole.

To ale @Kit neřekl.

Ale plyne to z toho.

Neplyne.

Mimo to, kolik začátečníků si hraje se zámky ?

Tak si misto zamek dopln: neuzavreny soubor, neuvolnene spojeni do databaze a souvisejici alokovane objekty, neuzavrene sitove spojeni. Opravdu to zacatecnici nepouzivaji?

Ne, začátečníci většinou končí neuzavřeným souborem, kdy se o to přinejhorším postará OS. Tím to neobhajuju. Paradoxně if - close - return je v tomto případě asi to nejlepší řešení, ty bys tam asi zase cpal else.

1) Strukturované programování je především o logické struktuře kódu, ne o nějakých pseudopravidlech.

A te struktury kodu dosahnes jak?

Tak, že nebudu program větvit na 150 if/else, aby celá funkce končila jedním returnem.

Mimochodem If/Else mají také za následek skok, tak přemýšlím, jak rozbíjí strukturu kódu.

Ja jsem k autistum tolerantni, ale vest s nimi diskuze o nicem me nabavi.

V pohodě, naštěstí autista nejsem, takže si rád nechám odpovědět na otázku.

O jaké struktuře kódu mluvíš?

Precti si neco o strukturovanem programovani, bude stacit wikipedie, urcite te to obohati.

Z wiki:

Kód: [Vybrat]

otevřít soubor;
while (existují data k přečtení) {
  načíst data;
  if (chyba) {
    ukončit podprogram a informovat zbytek programu o chybě;
  }
}
zpracovat načtená data;
konec podprogramu;
Výše je uvedena poměrně běžná situace, se kterou se můžeme vypořádat několika způsoby: vyhozením výjimky, předčasným (druhým) návratem z procedury a nebo třeba i příkazem skoku. Ve všech těchto případech má procedura dva výstupní body a porušuje tak principy „striktního“ strukturovaného programování. Na obhajobu tohoto přístupu však musíme říci, že přepsání této procedury v souladu s pravidlem jednoho výstupního bodu by bylo poměrně těžkopádné, nemluvě o tom, jaký chaos by v kódu vznikl, pokud by do hry vstoupilo více chybových stavů a každý se navíc musel ošetřit jiným způsobem.

Škoda, že sis takto naběhl. Bylo by fajn, kdybys uvedl, jak bys řešil např. ten main. Člověk, který uměle vynucuje jeden return na konci funkce, i když to prasí čitelnost, tak je stejné pako jako ten, kdo používá return na každém rohu.

[.]

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.

Tohle je možná fajn pro byznys logiku, ale zkuste takhle naprogramovat komunikační protokol.

[Reklama]

[Kit]

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.

Jistě, pokud používám funkce/knihovnu, kde se výjimky používají, tak pak není na výběr. Spíš mi šlo o to, proč bych měl na návratový kód "kašlat" (tento přístup), respektive vždycky upřednostňovat výjimky. Aspoň takový jsem z tvého vyjádření měl pocit.

Návratový kód mohu zapomenout ošetřit, což se zejména začátečníkům stává docela často. Když chybový status z knihovny přeložím na výjimku, tak mi to nedovolí ji ignorovat. Navíc taková výjimka obsahuje popis chyby a kde se stala.

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í.

Jistě, to dává smysl. Na stranu druhou když ošetřuji společně výjimky pro sekvenci příkazů, tak poté pravděpodobně ztratím tu "rozlišovací schopnost", co se kde stalo (jistě, ošetřuji třeba podobné/stejné problémy/výjimky, ale už je problém s tím kde, ne? Respektive chci-li řešit toto, tak to do kódu několik řádků přidá, či ne?).
To poslední beru, to je relevantní.

Každá výjimka je unikátní místem vzniku, stavovým kódem, vloženým textem a/nebo třídou výjimky. To vše si výjimka nese s sebou. Z toho se dají zjistit všechny potřebné informace a zpracovat je v jednom místě aplikace například pro všechny položky menu. To přináší značnou úsporu kódu a navíc výpis chybových hlášení pak vypadá jednotně. Pokud potřebuji jemnější granularitu, tak si v některé metodě mohu ošetřit jen některé typy výjimek a zbytek nechat propadnout. Také ji mohu obalit další výjimkou, takže si je mohu i vytrasovat.

[Kit]

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.

Tohle je možná fajn pro byznys logiku, ale zkuste takhle naprogramovat komunikační protokol.

Bez problémů.

[ded.kenedy]

vynucováním blbostí jí akorát tak ublížíš

V puvodnim prispevku bylo: pokud mam nekde if, melo by mit i else. Laskavy ctenar si povsimne, ze je tam pouzity podminovaci zpusob slovesa mit. Aby to bylo jasne "melo by mit" != "musi mit".

Tak, že nebudu program větvit na 150 if/else, aby celá funkce končila jedním returnem.

Pokud mas ve funkci 150 if/else, evidentne neco delas spatne. Ale zdraham se tu uvest stare dobre pravidlo, ze ve funkci by mely byt nanejvys tri nebo ctyri zanoreni if, for,... protoze nekterym by z toho mohla explodovat hlava.

Z wiki:

Kód: [Vybrat]

while (existují data k přečtení) {
  načíst data;
  ...
}
zpracovat načtená data;


Tento kod je hlavne z podstaty spatny, protoze funkce nedela jednu vec, ale minimalne dve veci: nacteni dat a jejich zpracovani. Pokud ty ulohy rozdelis, kod se da zjednodusit a vystacis si s jednim vystupnim bodem a kdyz budes vedet jak na to, muzes se obejit i bez break.

[Kit]

vynucováním blbostí jí akorát tak ublížíš

V puvodnim prispevku bylo: pokud mam nekde if, melo by mit i else. Laskavy ctenar si povsimne, ze je tam pouzity podminovaci zpusob slovesa mit. Aby to bylo jasne "melo by mit" != "musi mit".

Nemělo. Ve svých programech skoro žádné else nemám a nechybí tam. Občas se zbavuji i podmínek if, pokud je to vhodné.

Tak, že nebudu program větvit na 150 if/else, aby celá funkce končila jedním returnem.

Pokud mas ve funkci 150 if/else, evidentne neco delas spatne. Ale zdraham se tu uvest stare dobre pravidlo, ze ve funkci by mely byt nanejvys tri nebo ctyri zanoreni if, for,... protoze nekterym by z toho mohla explodovat hlava.

Obvykle stačí dvě úrovně zanoření, když se else nepoužívá. Těch 150 if/else byla jistě nadsázka.

[Cikáda]

vynucováním blbostí jí akorát tak ublížíš

V puvodnim prispevku bylo: pokud mam nekde if, melo by mit i else. Laskavy ctenar si povsimne, ze je tam pouzity podminovaci zpusob slovesa mit. Aby to bylo jasne "melo by mit" != "musi mit".

V původním příspěvku byla spousta hovadin. Vytrháváním z kontextu to neschováš. Btw pořád čekám na odpověď.

Z wiki:

Kód: [Vybrat]

while (existují data k přečtení) {
  načíst data;
  ...
}
zpracovat načtená data;


Tento kod je hlavne z podstaty spatny, protoze funkce nedela jednu vec, ale minimalne dve veci: nacteni dat a jejich zpracovani. Pokud ty ulohy rozdelis, kod se da zjednodusit a vystacis si s jednim vystupnim bodem a kdyz budes vedet jak na to, muzes se obejit i bez break.

Jistě, rozdělíme to, načteme data a pak je zpracujem. To je hezký, už jsi takhle načítal třeba několika gigový soubor?

Ale dobře, rádi se tu necháme poučit, hoď sem aspoň pseudokód, jak ty úlohy rozdělit, kód zjednodušit, atd.

Tak, že nebudu program větvit na 150 if/else, aby celá funkce končila jedním returnem.

Pokud mas ve funkci 150 if/else, evidentne neco delas spatne. Ale zdraham se tu uvest stare dobre pravidlo, ze ve funkci by mely byt nanejvys tri nebo ctyri zanoreni if, for,... protoze nekterym by z toho mohla explodovat hlava.

Obvykle stačí dvě úrovně zanoření, když se else nepoužívá. Těch 150 if/else byla jistě nadsázka.

[/quote]

Díky, už jsem se lekl, že to nešlo poznat. 

[Filip Jirsák]

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.

Že je potřeba uzavírat zdroje (ať už třeba soubory, paměť nebo zámky) patří k tomu splnění zadání. Programátor se to musí naučit, ne spoléhat na pochybné pravidlo, že když funkce doběhne až do konce, zdroje se uzavřou samy (a vedle toho mít druhé pravidlo, že na konci funkce je potřeba zdroje vždy uzavřít). Ono pak úplně stačí, že ve funkci drží zámek, z ní zavolá jinou funkci, která bude na to zámku také záviset, a má hezký deadlock. A bude se strašně divit, jak mohlo k něčemu takovému dojít, vždyť volání funkce přece není žádný return…

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!

Strukturovaný kód je strukturovaný, nikoli lineární. Z lineárního kódu se strukturovaný stane tak, že přidáte určité jasně definované skoky – podmínky (a cykly) a volání subrutin. Čistě lineárně bez jakýchkoli skoků byste toho moc nenaprogramoval.

[Kiwi]

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í.

Ale já stále nechápu, proč by "chybový stav" měl být nějak privilegovaný oproti jakémukoli jinému "normálnímu" stavu. Řekl bych, že ten komunikační protokol tu byl zmíněn dost trefně - když mi nepřijde ACK, tak je to "chybový" stav, nebo "normální" stav? CRC error je chybový stav, nebo normální? NAK mám generovat v rámci "normální" reakce, nebo v nějakém catchi?

Takovouhle záležitost prostě vyřeším formou stavového automatu, v němž jsou si všechny stavy rovny, na každý se nějak reaguje, což má opět za následek změnu stavu. Když chci otevřít soubor, který neexistuje - proč bych to měl ošetřovat někde jinde? Když nedostanu požadovanou paměť, když v parseru detekuji syntax error, když uživatel nějakého kreslícího programu neuzavře uzavřenou křivku, když v nějakém formuláři klikne na cancel místo ok - jsou to chyby, nebo "normální" stavy?

Právě naopak - přes výjimky vzniká špagetový kód, protože narušují tok programu. Jsou to skoky, ale nejen uvnitř procedur, ale dokonce napříč mezi procedurami a úrovněmi! Už samotný název - výjimky... Co je na chybě výjimečného? Proč bych ji měl řešit někde jinde než tam, kde vznikla? V mém kódu jsou takové situace tak výjimečné, že přesně zapadají do "tolerovaného" použití goto.

Pokud chci ošetřovat chyby tak, jak se má, tak mi všelijaké ty try-catche akorát zkomplikují práci a znepřehlední program. Pokud na to kašlu a chyba mi propadne někam dál, těžko se z takového místa na ni dá adekvátně reagovat - co bude dělat nějaká abstraktní vrstva s low-level chybou? To už je celé pak spíš debugovací nástroj.

[Filip Jirsák]

Ale já stále nechápu, proč by "chybový stav" měl být nějak privilegovaný oproti jakémukoli jinému "normálnímu" stavu.

Protože se na něj reaguje úplně jinak, než na normální stav. Pokud je stav normální, pokračuje program normálně v běhu. Pokud je stav chybový, může se program pokusit z něj nějak zotavit a vrátit program do nějakého normálního (předchozího nebo základního) stavu.

Představte si to třeba na bezpečných systémech. Když zabezpečovací systém na soupravě metra detekuje, že došlo k překročení maximální povolené rychlosti, nemůže se to řešit jako ostatní stavy, kde se řeší optimalizace rychlosti vzhledem k profilu tratě, grafikonu, cílovému brzdění atd. – nemůže tam mezi tím vším být schovaná podmínka „jo a pokud je překročená maximální rychlost, asi by bylo fajn začít brzdit“. Ne, ten chybový stav musí mít před vším přednost, všechno ostatní se zahodí a začne se řešit ten chybový stav – maximálním brzděním. A řešení toho chybového stavu skončí až tehdy, když je systém v nějakém jasně definovaném bezpečném stavu. Což by mohl být třeba návrat pod křivku maximální rychlosti, ale třeba v pražském metru je ten bezpečný stav až úplné zastavení soupravy. Teprve když souprava stojí, vrátila se do bezpečného normálního stavu, zruší se řešení chybového stavu a je možné pokračovat normálním způsobem, tj. strojvedoucí může soupravu znovu rozjet.

Když chci otevřít soubor, který neexistuje - proč bych to měl ošetřovat někde jinde? Když nedostanu požadovanou paměť, když v parseru detekuji syntax error

Třeba proto, abyste tu chybu vůbec ošetřil. Nebo protože jí potřebujete ošetřit na místě, kde ji vůbec nějak ošetřit můžete – což vůbec nemusí být místo, kde vznikla. Výjimky vám nebrání ošetřit chybu hned v místě, kde vznikla – ale nenutí vás k tomu. Pochybuju, že doopravdy ošetřujete možné chyby všude tam, kde teoreticky mohou nastat. Třeba při alokaci paměti.

[PetrM]

@balki, ded.kennedy:

Kašpárci, když už tady šaškujete se strukturovaným programováním, znáte i strukturogram?

Nás na průmce učili, že pokud se některá větev podmínky dotkne dolní hrany diagramu a nic nedělá (max. vrací nějakou hodnotu), můžeme tam natvrdo hodit return, protože to je to, co se doopravdy při jakékoliv konstrukci v programu po prohnání kompilátorem stane. A vo tom to celý je. Ne o nějakým dogmatu.

A pokud kompilátor hodí interně stejný kód pro return a pro jinou konstrukci, proč si tam přidávat další bloky a úrovně vnoření, který jsou přehledný jak Babišovy názory?

[balki]

@balki, ded.kennedy:

Kašpárci, když už tady šaškujete se strukturovaným programováním, znáte i strukturogram?

Nás na průmce učili, že pokud se některá větev podmínky dotkne dolní hrany diagramu a nic nedělá (max. vrací nějakou hodnotu), můžeme tam natvrdo hodit return, protože to je to, co se doopravdy při jakékoliv konstrukci v programu po prohnání kompilátorem stane. A vo tom to celý je. Ne o nějakým dogmatu.

A pokud kompilátor hodí interně stejný kód pro return a pro jinou konstrukci, proč si tam přidávat další bloky a úrovně vnoření, který jsou přehledný jak Babišovy názory?

Tak, vas to na priemyslovke ucili?    Ano, Nassi-Schniedermanove diagramy su velmi zriedka pouzivana technika modelovania algoritmov.  Raz to na nejakej prednaske vytiahol profesor, co robil kedysi s pocitacom Ural, ze aj take nieco bolo, pre zaujimavost.  Uz aj v tych casoch bol ale popularnejsi (dnes uz tiez zriedka pouzivany) flowchart.