Diskuze: Return bool vs. Throw Exception
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Tvůrce

Zobrazeno 22 zpráv z 22.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
bool se vracelo v jazyce C. Ale u spousty metod se vyplatí bool více(rychlost, přehlednost) -
např tryParse...
Výjimky se v zásadě používají vždy, pokud je něco špatně, i kdyby to mělo být v polovině případů. Pokud selže připojení k databázi, je to výjimka. Pokud je chyba v SQL dotazu, je to výjimka. Pokud někdo ve formuláři místo čísla domu napíše ulici, je to také výjimka.
Naopak se výjimky nemají používat k řízení toku programu. Ukončovat cyklus nebo metodu výjimkou, když vše proběhlo OK, se prostě nemá. Pokud proces proběhne přesně tak jak má, nikdy by k vyhození výjimky nemělo dojít.
Mě je jasný že Výjimky je lepší způsob, ale občas mě přijde že pouhé vracení bool je přehlednější, sám jak říkáš, třeba tryParse
Jasný A co například
použití v této situaci.
metoda načítá data (metoda jménem NactiData) například ze souboru. Uvnitř
NactiData mám Try/Catch blok ale zvenku, tedy kde metodu volám, chci vědět
pouze jestli se načetlo či ne (true / false). Je lepší výjimku z metody
NactiData zpropagovat dál, nebo aby vracela bool ?
Obvykle když načítám data, chci ta data. Pokud se nenačtou, tak je to prostě chyba. Nenapadá mě teď situace, kdy bych potřeboval načítat něco, co vlastně nechci. Jinak by se tedy vracel boolean, ale rozhodně bych metodu v tomhle případě nepojmenoval NactiData.
Já mám radši bool - takže bych ho určitě použil.
V tomto případě je zpravidla lepší tu výjimku v metodě vůbec nezachytávat a vypropagovat ji ven. Získáš tím i důvod, proč se data nenačetla a můžeš ho ze všech možných výjimek zachytit jedním catch a zalogovat nebo vypsat v dialogovém okně.
Výhodou je, že po návratu z metody, která může selhat, nemusíš vůbec nic testovat. Ani ten bool, ani výjimku. Tu si můžeš ošetřit klidně o pár úrovní výš. Aplikace se tím hodně zjednoduší.
Mám to ve Wrapperu, tedy takový Manager, který data drží a já pouze chci pouze říct, ať teď ty data načte. Manager mi ty data drží, umí je načíst i uložit. Takže ta metoda mi data nevrací, pouze říká a teď ty data načti. Tím pádem mě spíše zajímá akorát jestli se mu data podařila načíst.
Toť otázka asi bych tady
neviděl problém v použití bool, pokud prakticky řešíš jen zda se data
načetla či ne. Možná ale pokud budeš zohledňovat nějaký jiný postup u
toho, když by ti NactiData třeba vyhodilo chybu soubor neexistuje (zdroj), tak
pak je asi na zvážení, zda u této chyby nějak jinak zakročíš.
Pokud ne, tak je asi určitě lepší použít bool.
Jenže tebe nezajímá, jestli se data podařilo načíst. Dal jsi metodě rozkaz a ten musí splnit. Pokud ho nesplní, je to výjimka.
Hmm, to je právě co občas řeším . Ale z 90% výjimky používám. Takže asi i zde bude lepší
výjimku zpracovat.
Jenže výsledek toho bool musí zbytečně testovat a musí na výsledek nějak reagovat. To jen znepřehlední aplikaci.
Nemusíš nutně vracet bool, můžeš přeci rovnou vrátit zprávu s chybou a testovat ji na hodnotu null
Všechny chyby bys měl řešit přes výjimky, protože od toho v jazyce jsou. Koukni se na PHP, je tam vidět, co se stane, když se míchá výstup s chybovou hodnotou.
Pokud metoda vrátí null, proběhla OK? To bych ještě překousl, ale nepřekousnu, když dostanu hlášení o chybě datovým informačním kanálem místo chybového. Víš, jak blbě se to pak dál zpracovává?
Nevím jak těžký je pro tebe zpracovat instanci Systém.Exception
Když už mám výjimku, tak nemusím zpracovávat žádný boolean či null.
V tom s tebou souhlasím, já jsem měl na mysli spíš návratovou hodnotu metody
Zobrazeno 22 zpráv z 22.