> Miért csak az erőforrás felszabadítás szempontjából? A többi esetben működhet rosszul, ha egy hibát nem ott kezelünk, ahol kellene?
> Ezt egyébként se tartaná be senki, mert nem is lehet, ha meg betartaná, akkor teli lenne try-catch-csel az egész kód, ami nem kissé lassítani le az alkalmazást és tenné teljesen olvashatatlanná a kódot.
Ha nem ott kezeljük a hibát ahol kellene, az nem az eszköz hibája, hanem a használójáé. Az exceptiönt így kellene használni:
* Ha exceptiön jön az azt jelenti, hogy a hívott oldal nem futott le jól. _Ami erre a műveletre épül_ annak a további futtatásának nincs értelme. A saját erőforrásait felszabadította, de a hívó fél erőforrásait nyilván nem tudja.
* A catch helyét az határozza meg, hogy hol van az a pont, ahol hiba esetén is van értelme továbbfutni. Itt követik el a legtöbb hibát: teleírják catch-csel a programot, mert az ellenőrzött kivétel megköveteli. Pedig nem is tudnak kezdeni vele semmit, csak kiloggolják, és rossz értékekel fut tovább a program. Ez gyakori hiba, de én nem írnám az eszköz számlájára.
* A legtöbb esetben nincs értelme a különböző kivételeket külön kezelni: a megfelelő helyen el kell kapni, és loggolni, usernek hibaüzenetet adni, vagy becsomagolva továbbdobni. Mivel a hívott fél mindent elvarrt, ezért nincs értelme megkülönböztetni őket. Ritka kivétel, ha például van értelme újrapróbálni - pl adatbázis tranzakció exception esetén.
* Az ellenőrzöt kivételeket én sem szeretem, mert egyrészt arra utal, hogy ami nem dob ilyet, az nem dob semmit - dehogynem, RuntimeException-t bármi dobhat - másrészt meg arra sarkall, hogy ott is elkapjuk, ahol nem kéne - a throws nem ismerete miatt. Ezért nekem alapmintám, hogy elkapok mindent és becsomagolom egy RuntimeException-be. A másik, hogy minden függvényem throws Exception - mindent dobhat.
Szóval az exceptiön handling kicsit tényleg bonyolult, de hajlok arra, hogy ez inherens bonyolultság: a hibás esetek helyes lekezelése nem egyszerű feladat, és ahhoz képest ez még egy jó kompromisszum. Biztosan jobb, mint a C-ben gyakran használt kötelező visszatérési-érték ellenőrzés/elágazás végtelen mélységben. Pláne goto tiltással és egy visszatérési érték legyen formai követelményekkel karöltve szép mentális gimnasztika mindent megfelelően körbeiffelni.
Nézőpont kérdése, az execute around minta is tekinthető-e bonyolításnak? A vonatkozó stacoverflow oldalról:
https://stackoverflow.com/questions/341971/what-is-the-execute-around-i…
"It seems to me that the Execute Around Method is sort of like Inversion of Control (Dependency Injection) that you can vary ad hoc, every time you call the method."
Ráadásul a tipikus implementációban pont egy try/resource van benne. Mitől egyszerűbb ez, mint a try/resource?
Hátrányaiból ellenérvek:
> - elfelejthető a használata
compiler warningot tud adni rá, amit kezelhetünk errorként is
> - nem lehet többszálú végrehajtásnál használni
alapkiépítésben az execute aroundot sem. Több szálról használni egy erőforrást eléggé komplex önmagában, szerintem antipattern speckó esetektől eltekintve.