Jak můžu opustit funkci

[Kit]

A vynimky nie su strukturovane programovanie, to je len goto na iny sposob, to je vam hadam jasne.  Tie je vhodne vcas odchytit (tie predvidatelne) a riadenie programu robit pomocou chybovych hodnot.

Výjimky naopak zachycuji tak pozdě, jak jen to jde. Jejich nespornou výhodou je, že v sobě nesou všechny informace, které potřebuji k jejich zpracování. Používat něco takového ke generování chybových hodnot je podle mne hloupost, neboť se tím velké množství předávaných informací ztratí. Řízení programu podle výjimek nebo stavových kódů je uznávaným antipatternem.

Tohle jsem psal, ale je to něco jiného, než co jsi mi před chvílí podsunul.

[Reklama]

[Kit]

@Jirsak Napisem to takto. Switch bez breaku sa neda v C ani napriklad v jave rozumne pouzivat. Pascalovske "case" ano.

Neviem, ci ste ozaj nechapavy, alebo sa tak len tvarite.

Už jsem napsal hodně switchů, ve kterých nebyl ani jediný break. Od jisté doby tak píši všechny.

Bojim sa opytat na dovod.

Důvod je jednoduchý: Chci, aby mé programy byly jednoduše čitelné - break mi tam prostě překážel.

[balki]

A vynimky nie su strukturovane programovanie, to je len goto na iny sposob, to je vam hadam jasne.  Tie je vhodne vcas odchytit (tie predvidatelne) a riadenie programu robit pomocou chybovych hodnot.

Výjimky naopak zachycuji tak pozdě, jak jen to jde. Jejich nespornou výhodou je, že v sobě nesou všechny informace, které potřebuji k jejich zpracování. Používat něco takového ke generování chybových hodnot je podle mne hloupost, neboť se tím velké množství předávaných informací ztratí. Řízení programu podle výjimek nebo stavových kódů je uznávaným antipatternem.

Tohle jsem psal, ale je to něco jiného, než co jsi mi před chvílí podsunul.

Výjimky naopak zachycuji tak pozdě, jak jen to jde. Jejich nespornou výhodou je, že v sobě nesou všechny informace, které potřebuji k jejich zpracování.

[Kit]

Tohle jsem psal, ale je to něco jiného, než co jsi mi před chvílí podsunul.

Výjimky naopak zachycuji tak pozdě, jak jen to jde. Jejich nespornou výhodou je, že v sobě nesou všechny informace, které potřebuji k jejich zpracování.

Ano, tohle jsem psal. Ovšem tohle:

Potom odchytime vynimku na poslednom moznom mieste, lebo zvysny kod nie je dolezity a koder si moze dohladavat, preco sa veci nevykonali. Vsak kompilator to vsetko aj tak prelozi na skok.

jsem nepsal. To sis někde vycucal z prstu.

[balki]

Tohle jsem psal, ale je to něco jiného, než co jsi mi před chvílí podsunul.

Výjimky naopak zachycuji tak pozdě, jak jen to jde. Jejich nespornou výhodou je, že v sobě nesou všechny informace, které potřebuji k jejich zpracování.

Ano, tohle jsem psal. Ovšem tohle:

Potom odchytime vynimku na poslednom moznom mieste, lebo zvysny kod nie je dolezity a koder si moze dohladavat, preco sa veci nevykonali. Vsak kompilator to vsetko aj tak prelozi na skok.

jsem nepsal. To sis někde vycucal z prstu.

Disclaimer: Nechcem poucovat, ani nikomu nadavat. Ani nic, ani to nemusite citat pan Jirsak.

Ok, teraz budem pre zmenu nonkonformny ja. Nas ucili vynimky odchycovat neskor, na vyssej urovni abstrakcie a vyhadzovat hned, ako je to mozne, donedavna som to praktizoval (a stacilo to).  No v skutocnosti to v niektorych aplikaciach znemoznuje pruzne reagovat, tak ako by bolo treba. Komunikoval som cez modem s jednym obskurnym ebedded zariadenim cez debilny protokol. Riesit vynimky, ktore mohli nastat - neskorsie, na vyssej urovni, by mohlo znamenat, ze sa zariadenie uvedie do stavu, ktory nie je zelany. Taktiez kvoli monitoringu cez zabbix sa v programe nachadzalo kopec boilerplate monitoringoveho kodu, ktory sa nespravne zavolal a systemaci mi potom zaslali excel, kde im nesedeli ciselka.

Ono je to asi dobre "niekde" tak pouzit. Ale nad touto best practice skripem zubami.

[Reklama]

[Kit]

Ok, teraz budem pre zmenu nonkonformny ja. Nas ucili vynimky odchycovat neskor, na vyssej urovni abstrakcie a vyhadzovat hned, ako je to mozne, donedavna som to praktizoval (a stacilo to).  No v skutocnosti to v niektorych aplikaciach znemoznuje pruzne reagovat, tak ako by bolo treba. Komunikoval som cez modem s jednym obskurnym ebedded zariadenim cez debilny protokol. Riesit vynimky, ktore mohli nastat - neskorsie, na vyssej urovni, by mohlo znamenat, ze sa zariadenie uvedie do stavu, ktory nie je zelany. Taktiez kvoli monitoringu cez zabbix sa v programe nachadzalo kopec boilerplate monitoringoveho kodu, ktory sa nespravne zavolal a systemaci mi potom zaslali excel, kde im nesedeli ciselka.

Ono je to asi dobre "niekde" tak pouzit. Ale nad touto best practice skripem zubami.

Pokud potřebuji jemnější granularitu, tak výjimku podle jejího typu zpracuji už v některé z mezivrstev. Buď ji vyřeším, anebo ji obalím a nechám propadnout. Vše závisí na protokolu mezi vrstvami, jehož součástí jsou i výjimky.

[PetrM]

@PetrM - for(; je taky "smysluplné", je nějaký důvod proč nepoužít while?

while(1) obsahuje magickou konstantu. A jedno z pravidel (na rozdíl od Balkiho nesmyslu s jedním returnem ve funkci je rozumný) zní, že mimo nuly a dekrementu o 1 v mezích pole nesmí být v kódu nepojmenovaná konstanta. Tak jsem použil verzi bez čísla.

Ono s for se dá dělat hodně kouzel... 

[Cikáda]

@PetrM - for(; je taky "smysluplné", je nějaký důvod proč nepoužít while?

while(1) obsahuje magickou konstantu. A jedno z pravidel (na rozdíl od Balkiho nesmyslu s jedním returnem ve funkci je rozumný) zní, že mimo nuly a dekrementu o 1 v mezích pole nesmí být v kódu nepojmenovaná konstanta. Tak jsem použil verzi bez čísla.

Jenže to v tomto případě není ani tak numerická konstanta, jakožto spíš boolean. While (true) je úplně standardní konstrukce, tak by mě zajímalo, v čem je (by mohl být) problém?

Ono s for se dá dělat hodně kouzel... 

To jistě, ale nevidím jediný důvod, proč bych měl psát

Kód: [Vybrat]

for(;;) { // Hlavni smycka
    if(isEnd()) break;
    ...
}

když můžu napsat toto

Kód: [Vybrat]

while(!isEnd()) {
    ...
}

Je to čitelnější, kratší, imho elegantnější.

[PetrM]

Jenže to v tomto případě není ani tak numerická konstanta, jakožto spíš boolean. While (true) je úplně standardní konstrukce, tak by mě zajímalo, v čem je (by mohl být) problém?

Problém je třeba v tom, že žádný true není v C definováno. A testovat v C proti true je sebevražda. Proč by to  měl člověk dělat při nekonečné smyčce?

Navíc pokud předpokládáme, že se funkce isExit() zabývá nějak vnitřním stavem hlavní smyčky, je nesmysl to volat hned na vstupu. Pokud nevybleješ průchod smyčkou ještě jednou před ni. Takže pokud chceš opravdu testovat isExit() na okraji smyšky, je vhodnější do-while podle principu DRY.

Každopádně endless loop + break má výhodu v tom, že můžeš testovat kdekoliv - na začátku smyčky zpracuješ události, aktualizuješ stav a můžeš testovat, jestli je to stav pro ukončení. Zbytek logiky smyčky nemusíš při ukončení brát v potaz...

Nevidím důvod, proč psát

Kód: [Vybrat]

  ...
  updateSa();
  while(s != STATE_EXIT) {
    updateSa();
    if(s != STATE_EXIT) {
      ...
    }
  }

když můžu napsat

Kód: [Vybrat]

  for(;;) {
    updateSa();
    if(s == STATE_EXIT) {
       break;
    }
    ... // Neprovede se pri ukonceni
  }

a mít tam jednu podmínku místo dvou (2 stejný podmínky bez optimalizace = 2x zahazování pipeline, rozhození dvoubitovýho prediktoru skoků,...)

[Filip Jirsák]

Jak zapsat nekonečnou smyčku obvykle patří ke konvencím daného jazyka případně projektu. Způsobů je obvykle několik a měl by se používat jen jeden z nich, aby nad tím pokaždé nemusel programátor přemýšlet „jo aha, tohle je také nekonečná smyčka“. V C se pokud vím obvykle používá for (;;), v Javě je konvence nekonečnou smyčku psát jako while (true).

[balki]

@PetrM - for(; je taky "smysluplné", je nějaký důvod proč nepoužít while?

while(1) obsahuje magickou konstantu. A jedno z pravidel (na rozdíl od Balkiho nesmyslu s jedním returnem ve funkci je rozumný) zní, že mimo nuly a dekrementu o 1 v mezích pole nesmí být v kódu nepojmenovaná konstanta. Tak jsem použil verzi bez čísla.

Ono s for se dá dělat hodně kouzel... 

To bolo podla dogmy, ktoru mi pripisujete.
Nekonecne slucky su nesvar. (Dufam, ze to jirsak necita, lebo zasa ta zaplava hovien bude neudrzatelna)

[Ondra Satai Nekola]

Nekonecne slucky su nesvar. (Dufam, ze to jirsak necita, lebo zasa ta zaplava hovien bude neudrzatelna)

V event driven programu je jedna nekonecna smycka tak akorat ;-)

Samozrejme nemusis ji psat rucne, pokud mas k ruce dobry framework.

[balki]

Nekonecne slucky su nesvar. (Dufam, ze to jirsak necita, lebo zasa ta zaplava hovien bude neudrzatelna)

V event driven programu je jedna nekonecna smycka tak akorat ;-)

Samozrejme nemusis ji psat rucne, pokud mas k ruce dobry framework.

Co oci nevidia, to srdce neboli     Minimalne je fajn mat moznost taku slucku rozpojit. Vzdy sa tam da dopisat boolean, ked treba.  Ale chapem, ze asi kompilator nekonecnu slucku asi vidi a patricne zoptimalizuje.

[dustin]

Ve škole nás učili...

Lepší je používat vlastní rozum.

Výjimka se chytá tam, kde to dává pro danou konkrétní situaci smysl.

[PetrM]

Nekonecne slucky su nesvar.

Jak uděláš thread v RTOSu bez nekonečné smyčky? (jinde než v threadech na RTOSu a v main() jsem ještě nekonečnou smyčku nepoužil)

Jo aha, multitasking a multithreading je nešvar. Špagety v main() rulezzz, ať je z toho Arduino style žumpa bez možnosti reuse a údržby...