Čo sa stane, keď v triede Thread1 premenujete metódu run()?
Čo sa stane, keď v triede Thread2 premenujete metódu run()?
Všimnite si použitie referencie na metódu a lambda výrazu.
Dokončte triedu Thread5 pridaním zodpovedajúcej anonymnej triedy. Vychádzajte z triedy Thread2.
Experimentujte so synchronizáciou nití prostredníctvom príkladu Incrementer-Printer z prednášky.
Čo sa stane, keď odstránite kľúčové slovo synchronized z jedného alebo oboch miest, na ktorých sa vyskytuje?
Všimnite si, že synchronizácia vlastne znamená uzamknutie objektu pre určitý kritický región (blok kódu). Identifikujte kritické regióny a objekt v príklade Incrementer-Printer. Nahraďte synchronizáciou celej metódy synchronizáciou bloku kódu (poskytnutá v komentári). Zmení sa niečo?
(Na domácu úlohu.) Prerobte príklad Incrementer-Printer tak, aby nevyužíval žiadne statické prvky. Aký objekt má byť uvedený vo výraze synchronized(), ak uplatnite synchronizáciu na úrovni bloku kódu ako v predchádzajúcej úlohe?
Vyskúšajte príklad s delením a to ako bez ošetrených výnimiek, tak aj s ošetrenými výnimkami.
Ak používate Eclipse, argumenty programu zadajte pomocou voľby Run Configurations…
Experimentujte s kódom hry s obrami a rytiermi z prednášky, v ktorom je ošetrený nerovnaký počet obrov a rytierov zavedením a ošetrením zodpovedajúcej výnimky.
Toto je tzv. kontrolovaná výnimka: musí byť ošetrená.
Čo sa stane, ak odstránite jej ošetrenie (try-catch blok)?
Zostáva tam ešte jeden problém: používateľ vôbec nemusí zadať čísla. Ako by ste ošetrili toto?
Všimnite si ošetrenie výnimky NoSuchElementException v prijímači tlačidla nextClashButton v triede ClashWindow. Toto je výnimka typu RunTimeException, a tie sa nekontrolujú, t. j. prekladač nevnucuje ich ošetrenie (tri ďalšie typy nekontrolovaných výnimiek ste mali možnosť vidieť v príklade s delením).
Ošetrenie výnimiek pri použití triedy Task<V>, ktorá sa používa na spustenie výpočtu mimo nite, v ktorej sa vykonáva GUI (JavaFX), je trochu zložitejšie, lebo táto trieda nepropaguje výnimky priamo, ale ich eviduje. Prijímač tlačidla nextClashButton v triede ClashWindow demonštruje dva varianty zachytenia výnimky NullPointerException (ďalšia nekontrolovaná výnimka):
cez sledovanie zlyhania úlohy a cez sledovanie objektu, ktorý sa používa na ukladanie výnimiek.
Pozrite príklad s výnimkou pri prekonávajúcej metóde.
Prekonávajúca metóda nemôže zaviesť nový typ výnimky. Musí sa držať typov výnimiek, ktoré deklarovala metóda, ktorú prekonáva.
V našom príklade by sa klientsky kód (trieda C) mohol spoliehať na všeobecnejšiu deklaráciu metódy m() v triede A a ignorovať výnimku typu Exception.
Čo by sa stalo, keby metóda B.m() deklarovala, že vyhadzuje výnimku MySubexception odvodenú od výnimky MyException?
Treba v takom prípade upravovať blok spracovania výnimky v klientskom kóde?
V hre z prednášky pribudla aj metóda na spočítanie bojovníkov (Game.countWarriors()). Do GUI sú zaradené aj príslušné ovládacie prvky. Všimnite si použitie metódy isInstance() (namiesto operátora instanceof) na zisťovanie typu bojovníka a zabezpečenie kontroly typu s využitím generickosti triedy Class.
Ktorá trieda implementuje metódu isInstance()? Pozrite túto triedu v dokumentácii Java API a čo všetko prostredníctvom nej možno zisťovať.