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
throwszá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
iocsomag 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 athrowszá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 anullokozta problémákat.A legjobb megoldás utólag. De
Az
Eitheregyébként semmiben nem különbözik egy ellenőrzött kivételtől.