Diskuze – Lekce 4 - Java GUI
ZpětUpozorňujeme, že diskuze pod našimi online kurzy jsou nemoderované a primárně slouží k získávání zpětné vazby pro budoucí vylepšení kurzů. Pro studenty našich rekvalifikačních kurzů nabízíme možnost přímého kontaktu s lektory a studijním referentem pro osobní konzultace a podporu v rámci jejich studia. Toto je exkluzivní služba, která zajišťuje kvalitní a cílenou pomoc v případě jakýchkoli dotazů nebo projektů.
Lubor Pešek:12.7.2021 0:34
Je to sice už 8 let, ale zajímavé, že si toho za celou dobu nikdo
nevšiml.
Je jasné, proč tvůj kód dopadl tak, jak říkáš. Protože ty dělíš
íčko, které je v interaci nulou pouze jednou. Takže je to jasné - v prvním
případě zaměstnáváš počítač podmínkou, která bude jen v jednom
případě nulou a pak to "zatěžuješ podmínkou", ale ve druhém případě
to do catch bloku projde pouze poprvé a pak ten kód prostě projde a catch se
neuskuteční.
Proto ti to vyjde, že je ve tvém případě try i 5x rychlejší.
Jenže když použiješ třeba toto:
public static void main(String[] args) {
long start = System.currentTimeMillis();
int a = 1;
int b = 0;
int c;
for (int i = 0; i < 1_000_000_000; i++) {
if (b != 0) {
c = a / b;
} else {
c = 0;
}
}
System.out.println(System.currentTimeMillis() - start);
start = System.currentTimeMillis();
for (int i = 0; i < 1_000_000_000; i++) {
try {
c = a / b;
} catch (ArithmeticException exp) {
c = 0;
}
}
System.out.println(System.currentTimeMillis() - start);
}Tak dostaneš výsledek s podmínkou v řádu milisekund a s výjimkou v řádě sekund.
A to se jedná o jednu jednoduchou operaci. Bez multithreadingu.
Mě osobně ten rozdíl v průměru vycházel tak, že jsem podmínku měl v
rozmezí 5-7 milisekund na miliardu případů a pro stejný počet (když už
zafungoval catch) tak to bylo v rozmezí mezi 1050-1070 milisekund)
A to je sakra rozdíl, to se na mě nezlob.
Mám za to, že jste to všichni mysleli dobře a určitě výjimky jsou na to, aby se používali. Ale dovedeš si fakt představit, že by ti složitá aplikace někde padala na výjimku a teď by to provádělo nějaký složitější formulář a třeba se s tou výjimkou složitě pracovalo dál? Hlavně u webových služeb (a nedejbože u nějaké komunikace mezi serverem a clientem) by to bylo už dost fatální.
Fugiczek má naprostou pravdu, že v předvídatelných situacích je efektivnější použít podmínku. Výjimky se mají pokud možno ošetřovat až na formulářích (aby to "probublalo" do míst, kde to mohl hlavně uživatel dokur***).
vVýjimky by se hlavně měli používat z logiky podstaty tak, aby kvůli
nějaké chybě nespadl celý systém, ale aby se chyba zachytila a pokračovalo
se dál.
A určitě - jak jsi uváděl, tak je to pro ošetřování výjimečných
stavů, ale rozhodně nemůžeš přeci napsat, že složitá konstrukce
výjimky bude rychlejší, než podmínka. Podmínka je skutečně jednoduché
porovnání logického výrazu a hotovo. Výjimka začne být zatěžující v
momentě, kdy vstoupí právě do catch bloku.
PS: teď se mi to machruje, ale také jsem rval výjimky, všude možně 
Až když jsem řešil
performance testy u rainy days, tak pak jsem viděl, jak je prospěšnější
zachytávat předpokládanou chybu obyčejnou podmínkou 
A popravdě - co může nastat za jiný problém u dělení, než nula?
Chápu, že Samik určitě dobře myslel na to, aby učil od začátku
ošetřovat takové případy, ale skutečně začátečníci jsou rádi, že se
jim vůbec něco zobrazí. Rvát sem výjimku bylo trošku matoucí a fakt je to
na samostatný tutorial.
Zobrazeno 3 zpráv z 23.