- enpassant blogja
- A hozzászóláshoz be kell jelentkezni
- 1163 megtekintés
Hozzászólások
Ugyan már, mi az az Exception? Option[T] vagy Either, aztán jól vagyunk :-)
Szerk: vagy Try[T] ha más nem.
- A hozzászóláshoz be kell jelentkezni
Melyik Try implementációt használod?
- A hozzászóláshoz be kell jelentkezni
Egyelőre egyikre se volt szükségem, az Option[T] eddig megfelelt.
- A hozzászóláshoz be kell jelentkezni
Mármint Optional. De az nem Try monad, nem exception kezelésre való.
Ja hogy te nem Javaról beszélsz... ok.
- A hozzászóláshoz be kell jelentkezni
Igen, enpassant mindég felerősíti amúgysem csekély szeretetemet a Scala nyelv iránt.
Azt mondanám, hogy az Option[T] a NullPointerExceptionok kiváltására nagyon pöpec.
(Amúgy a Scala-m nem tökéletes, mindég foreach-et hívok for <- helyett, illetve a for/yield-et sem szoktam használni, pedig biztos szebb kódot eredményezne. Egyszerűen még nem szoktam rá.)
- A hozzászóláshoz be kell jelentkezni
Ha már szóba került a Scala, akkor itt van egy csokor, hogyan érdemes Scala-ban hibát kezelni:
- A hozzászóláshoz be kell jelentkezni
azért az ábra cuki a printStackTrace-szel, meg az üres blokkal. De a sout is tetszik...
Mondjuk arra kíváncsi lennék, a githubos projekteknek hány százaléka valami hobbi projekt, amiben a működjön hamar a cél, s hány százaléka productionre szánt kód (ahol mondjuk a hosszú fenttarthatóság is cél). Ebből valszeg látszik, nem olvastam el - még - a tanulmányt.
de +1 wachag-nak, az Java-s exception kezelés kicsit idejemúlt - külön öröm megtanulni egyetemre, melyik az az Exception, aminek „elkapása nem kötelező, elkapása zajt visz a kódba”.
--
blogom
- A hozzászóláshoz be kell jelentkezni
"Mondjuk arra kíváncsi lennék, a githubos projekteknek hány százaléka valami hobbi projekt, amiben a működjön hamar a cél, s hány százaléka productionre szánt kód (ahol mondjuk a hosszú fenttarthatóság is cél)."
Erre én is kíváncsi lennék, de ezt nem igazán lehet megállapítani!
- A hozzászóláshoz be kell jelentkezni
"Arra a konklúzióra jut, hogy a fejlesztők többsége figyelmen kívül hagyja a checked exception-t és nem kezeli megfelelően. A más típusú exception-ökkel is hasonló a helyzet. A fejlesztők hozzáállásától és képességétől függ, hogy megfelelően kezelnek-e egy exception-t"
És a projektre érvényes minőségi követelményektől.
Mást jelent a "megfelelően" egy repülésirányító szoftvernél (ilyen úgysincs githubon), egy komoly nyílt forrású projektnél, egy akadémiai kutatási projektnél (élje túl a demót és a benchmarkot), vagy egy hobbiprojektnél (egy sehol se dokumentált formátumú bemenetre adjon értékelhető kimenetet, de hogy azon kívül mi történik, az teljesen lényegtelen). Pragmatikusan nézve utóbbi két esetben a
printStackTrace(); exit(42); kivételkezelés "megfelelő".
Sajnálatos, hogy erről egy szó sincs Threats to Validity szakaszban, pedig alapvető jelentőségű.
"... azt nyelvi eszközökkel (checked) nem lehet kikényszeríteni."
Dehát ez mindig is nyilvánvaló volt, nem? A nyelvi eszközök csak a checked exception miatt kötelező catch blokk meglétét követelik meg, de hogy egy catch blokkba mi kerül, abba már nincs, és nyilván nem is lehet beleszólásuk.
- A hozzászóláshoz be kell jelentkezni
A tanulmányban azt vizsgálták, hogy a J. Bloch. E↵ective Java (2Nd Edition) könyvben megfogalmazott legjobb gyakorlatokhoz képest hogyan kezelik és nem azt, hogy az adott projektben az még megfelelő-e, mivel ez utóbbit nem is lehet mérni.
"Dehát ez mindig is nyilvánvaló volt, nem?"
Elvileg ez lenne a checked exception (a nem checked-hez képest) lényege, hogy kényszerítse a hiba kezelését. Gyakorlatban viszont, legtöbb esetben, több kárt okoz, mint hasznot, hiszen csak elkapják az exception-t és nem kezelik. Ennél az is jobb lenne, ha nem checked lenne és el sem kapnák.
Tehát a tanulmány mondanivalója kvázi az, hogy a checked exception, még ha (egyesek szerint) elméletileg jó is volna, a gyakorlatban rossznak bizonyul.
- A hozzászóláshoz be kell jelentkezni
Kis olvasnivaló: http://www.artima.com/intv/handcuffs.html
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
azert kivancsi lennek, hogy mi szamit megfelelonek, mert szerintem a sajat runtimeexception-be wrappolas pl teljesen okes (es pl esetleg ezeket fail fast strategiaval kezelve)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Valószínűleg nem jó szó a megfelelő, ha tudtok jobbat, akkor lecserélem!
"A tanulmányban azt vizsgálták, hogy a J. Bloch. E↵ective Java (2Nd Edition) könyvben megfogalmazott legjobb gyakorlatokhoz képest hogyan kezelik és nem azt, hogy az adott projektben az még megfelelő-e, mivel ez utóbbit nem is lehet mérni.
- A hozzászóláshoz be kell jelentkezni
megfelelő exception kezelés:
int doSomething(){
try{
....
} catch (Throwable t)
{return 1;}
return 0;
}
- A hozzászóláshoz be kell jelentkezni
Elromlott az iróniadetektorom, vagy ez mitől lenne mégis megfelelő?
(Meg úgy egyáltalán, miért kellene minden exceptiont lekezelni. Az Exceptionaim kb. 95%-a nálam olyan, hogy általában az a legjobb "kezelés" rá, hogy kap az user egy hibaüzenetet a képébe és hagyom meghalni az egész folyamatot és hagyom, hogy három rétegen keresztülszáguldjon az Exception, mert semelyik szint nem tud vele érdemben foglalkozni.
(A "kap egy hibaüzenetet" megjegyzést kéretik szabadon értelmezni: ebben benne van a sima hibaüzenet-ablaktól a komplexebb naplózásos, hibaesemény-gyűjtős-megnézem a dashboardon megoldásig mindenféle.)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az 5%-ról van szó, amikor checked exception-t használnak, elvileg azért, mert javítani lehet a hibát megfelelő kezeléssel.
- A hozzászóláshoz be kell jelentkezni
Na de amikor te egy publikus metódust írsz, nem tudod, hogy milyen kontextusból fogják azt meghívni és, hogy az tud (vagy akar-e) kezdeni bármit is az exceptionoddal?
Példa: van egy metódusod, ami valamilyen fájlt dolgoz fel és ad vissza adatokat. A fájl megnyitásakor te kapsz egy FileNotFoundException-t. Mivel te csak a betöltéssel foglalkozol, nem tiszted eldönteni, hogy mi legyen vele ezért továbbdobod.
Viszont azt, hogy a hívó az egy UI-val rendelkező alkalmazás, ahol az exception úgy lesz lekezelve, hogy feltesz egy kérdést, hogy létrehozza-e a fájlt vagy igazából le se szarja, mert egy háttérben hívott feldolgozó program, ami igazából meg is pusztulhat onnan kezdve, hogy nem tudja megnyitni a fájlt. (Ahogy replaced is mondta: fail fast megközelítés).
Neked, mint egy interface implementálójának nem igazán van közöd ahhoz, hogy a külvilág hogyan fogja meghívni az interfaced (most tekintsünk el attól, mikor nyilvánvalóan érvénytelen állapotba/hibás paraméterekkel/stb. próbál valaki hívni). Checked exceptionnal viszont rákényszerítesz a hívó részére egy olyan hibakezelést, amikor igazából egyáltalán nem biztos, hogy érdemben tud vele bármit is kezdeni. Az meg nem igazán érdemi hibakezelés, hogy beburkolod az exceptiont egy másikba, ha egyébként semmi szükség rá.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"Checked exceptionnal viszont rákényszerítesz a hívó részére egy olyan hibakezelést, amikor igazából egyáltalán nem biztos, hogy érdemben tud vele bármit is kezdeni."
Ez amit írsz az már azt feszegeti, hogy a checked exception-nek még elvileg sincs értelme (amivel én egyet is értek).
- A hozzászóláshoz be kell jelentkezni
Igen, pontosan.
Pontosabban: értelme lenne, de nem oldja meg azokat a problémákat, amelyekre létrehozták, illetve további olyan plusz mellékhatásai vannak, amik miatt szerintem nem sok értelme van.
Az okokat nagyjából jól elmondta Anders Hejlsberg a Bat által linkelt interjúban.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
"Teljesen okes", de ez a megoldás is azt igazolja, hogy ott felesleges volt a checked exception, jobb lett volna egy unchecked exception és akkor még a kódomat sem kellett volna elcsúfítanom a boilerplate kóddal.
- A hozzászóláshoz be kell jelentkezni