Szerintem rettentő kényelmetlen a throws záradék sok-sok (értsd: egynél több) szinten történő keresztülvezetése. De hát a Java eleve egy elég verbose nyelv, aminek megvannak a maga előnyei/hátrányai, ettől még semmiképpen sem RuntimeException-ökkel próbálnám meg megkerülni a problémát.
A kérdés az, hogy valóban indokolt-e a hiba továbbengedése az esetek számottevő részében. Egy Integer.parseInt() hívásból adódó NumberFormatException-t érdemben nem lehet kezelni, csak a hiba helyén. Úgy érzem, hogy túl van értékelve ez az eset, nem kis részt azért, mert könnyű hozzászokni ahhoz, hogy a hibákat nem kezeljük, csak odafenn naplózzuk.
Persze az sem segít a helyzeten, hogy az io csomag szinte minden hívása dobhat IOException-t, bármiféle magyarázat nélkül, így lehetetlenné téve, hogy kezeld – marad a logolás, és a throws záradékok vagy a csomagolás futásidejűbe.
Mindenesetre érthetetlen számomra, hogy emberek úgy fejlesztenek statikus nyelvekben, hogy a fordító nemhogy nem tud a hívások minden lehetséges visszatérési értékéről, de gyakorlatilag bármelyik hívás következtében, bármikor összeomolhat a rendszer – miközben a statikus típusrendszernek az lenne az értelme, hogy garantálja a program ha nem is helyes, de kiszámítható futását.
Ugyanez érvényes egyébként a null-ra, ami ugyanilyen kiskapu a típusrendszeren.
Mostanában sokat olvasok a funkcionális programozásról, nekem eddig úgy tűnik, hogy a Maybe (és társai) elég hatékonyan meg tudják oldani a null okozta problémákat.
Szerintem
throws
záradék sok-sok (értsd: egynél több) szinten történő keresztülvezetése. De hát a Java eleve egy elég verbose nyelv, aminek megvannak a maga előnyei/hátrányai, ettől még semmiképpen semRuntimeException
-ökkel próbálnám meg megkerülni a problémát.A kérdés az, hogy valóban
Integer.parseInt()
hívásból adódóNumberFormatException
-t érdemben nem lehet kezelni, csak a hiba helyén. Úgy érzem, hogy túl van értékelve ez az eset, nem kis részt azért, mert könnyű hozzászokni ahhoz, hogy a hibákat nem kezeljük, csak odafenn naplózzuk.Persze az sem segít a helyzeten, hogy az
io
csomag szinte minden hívása dobhatIOException
-t, bármiféle magyarázat nélkül, így lehetetlenné téve, hogy kezeld – marad a logolás, és athrows
záradékok vagy a csomagolás futásidejűbe.Mindenesetre érthetetlen számomra, hogy emberek úgy fejlesztenek statikus nyelvekben, hogy a fordító nemhogy nem tud a hívások minden lehetséges visszatérési értékéről, de gyakorlatilag bármelyik hívás következtében, bármikor összeomolhat a rendszer – miközben a statikus típusrendszernek az lenne az értelme, hogy garantálja a program ha nem is helyes, de kiszámítható futását.
Ugyanez érvényes egyébként a
null
-ra, ami ugyanilyen kiskapu a típusrendszeren.Maybe, Either
Maybe
(és társai) elég hatékonyan meg tudják oldani anull
okozta problémákat.A legjobb megoldás utólag. De
Az
Either
egyébként semmiben nem különbözik egy ellenőrzött kivételtől.