Diskusia – Java GUI

Mam k tomu 2 vyhrady.

1. Proc tu vysvetlujes slozity GridBagLayout, ktery ma o hodne vic vlastnosti nez jsi pouzil ty a obsahuje vetsi problematiku. Navic jsi pouzil vlastnosti, ktere jsou i u GridLayout (rozestoupeni tam nastavis uz v kontruktoru a nemusis urcovat pozici x a y, proste to zadas poporade) a pro zacatecniky je mnohem lepsi k pochopeni.
2. Osetrovat deleni nulou vyjimkou je pekna prasarna. Vyjimky jsou hlavne dobre kdyz program ladis. Vetsina vyjimek se pak osetruje ifama protoze vyjimky celkem brutalne zpomaluji beh aplikace, i kdyz tady to moc nepoznas.

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 ArithmeticExcep­tion. 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.