Upozorňujeme, že diskusie pod našimi online kurzami sú nemoderované a primárne slúžia na získavanie spätnej väzby pre budúce vylepšenie kurzov. Pre študentov našich rekvalifikačných kurzov ponúkame možnosť priameho kontaktu s lektormi a študijným referentom pre osobné konzultácie a podporu v rámci ich štúdia. Toto je exkluzívna služba, ktorá zaisťuje kvalitnú a cielenú pomoc v prípade akýchkoľvek otázok alebo projektov.
Určení souřadnic je univerzální. Co pokud bys chtěl například tři
řádky vynechat? Na výjimce jsem chtěl ukázat, že catch blok se provede
při jakékoliv chybě. 
Tak to logicky rozdelim na vice casti, nebo druha varianta je to vyplnit prazdnym JLabelem. Jde o to ze na tuto ukazku staci GridLayout, ktery bude vypadat uplne stejne stejne. GridBagLayout je overkill ktery zmate akorat zacatecniky. Toto je myslim serial o GUI ne o vyjimkach. Pokud ji chces tak moc pouzivat tak aspon nepouzivej vseobecnou vyjimku ale vyjimku ktera se pro to nejvice hodi, zde je to ArithmeticException. Takhle jde akorat videt ze tomu jazyku vubec nerozumis a nevis kdy je co vhodne pouzit...
"Osetrovat deleni nulou vyjimkou je pekna prasarna" - Na to jsi přišel jak? Přesně k tomu výjimky jsou. Proč bys odchytával výjimky, když program ladíš? To je chceš přeci naopak nechat, abys viděl, kde je chyba. Odchytneš je uživateli, aby mu aplikace nespadla. To, co jsi uvedl s tou podmínkou, je tzv. aktivní ošetření chyb, moc se to nepoužívá, protože výjimky jsou jediná správná cesta, jak s chybovými stavy aplikace pracovat.
Nevidim zadny duvod, proc by tu ta vyjimka byt nemohla nebo nemela, sice je
vyhozeni vyjimky o nekolik radu pomalejsi nez hola podminka, ale zrovna u
kalkulacky to asi nikoho moc netizi.
Vyjimkam bych se vyhnul az kdyz jde o nejaky kod, ktery musi bezet rychle a
spousti se vicekrat za vterinu.
Zrovna deleni nulou je klasicky pripad na pouziti vyjimky, sice tady v tom programu muze chyba nastat jen pri deleni nulou, ale je to uz aspon hezky pripraveno treba pro pridani dalsich matematickych funkci, jako jsou tangens apod, ktere mohou vyhodit chybu s nekterymi parametry, pak bys musel osetrovat kazdy pripad rucne, na to je mnohem lepsi vyjimka (jak uz jsem psal vyse - pokud to neni casove kriticke, pak by se vyplatilo udelat optimalizaci a misto obecne chyby resit kazdy pripad podminkou a zvlast).
V něčem máš pravdu. Na druhou stranu si ale myslím, že u chyb tohoto typu, je lepší jim předcházet, než je řešit až když nastanou, respektive zařídit, aby se nulou vůbec dělit nedalo a pak by ta metoda vrátila třeba řetězec "Nulou nelze dělit!". Zase ale, pokud není třeba zjistit v čem přesně chyba nastala, pak je lepší výjimka, protože když nastane chyba někde jinde, výjimka to zachytí. Takže si myslím, že správně je oboje. Co se mi spíš nelíbí, je docela dost dlouhý kus kódu v bloku try, dal bych to do nějaké privátní metody.
Výjimky byly v objektových jazycích zavedeny proto, aby se používaly. Testovat dělitele na nulu před vlastním dělením je hloupost, která se může vymstít například při vícevláknovém zpracování. Výjimka je v daném případě rychlejší, než vytváření zbytečných kritických sekcí.
To ale nemění nic na tom, že ten kód v té výjimce je delší než by
musel
"Testovat dělitele na nulu před vlastním dělením je hloupost, která se může vymstít například při vícevláknovém zpracování. Výjimka je v daném případě rychlejší, než vytváření zbytečných kritických sekcí."
Naprosto chybné.
Teď jsem to schválně testoval, výjimek za sekundu se stihlo provést asi 280
(!), zatímco přístupů k proměnné v kritické sekci ze dvou vláken cca 40
000 000.
To si schválně zkusím udělat také, protože ten tvůj výsledek vypadá velmi podivně. 280 výjimek za sekundu je hrozně málo. Jako kdybys to honil přes GUI.
Zatiaľ nikto nevložil komentár - buď prvý!