Hm, nie pozwala? Albo jestem głupi, albo ten przykład właśnie pokazuje jak wyjątek jest łapany w zależności od klucza w mapie - https://github.com/scgilardi/slingshot#usage
czy java to robi dobrze to bym sie klocil. generalnie sensowna obsluga wyjatkow to dosc ciezka rozkmina i jak narazie najbardziej to mi sie podobala taka opcja: http://michaeldrogalis.tumblr.com/post/40181639419/trycatch-complects-we-can-do-so-much-better w funkcji piszesz sobie pozytywna sciezke kiedy zakladasz ze sie nic nie wyjebie. a dla roznych typow wyjatkow piszesz sobie osobne handlery
fajna opcja jest tez monada maybe i ze Ci nothing po prostu przecieka dalej zwlaszcza jak masz kod w stylu (-> something other-something call-something-else) ale szczegolnie przy interopie z java i tak nie wiesz czy cos gdzies Ci nagle nie wybuchnie i tak bys musial sobie try/catche robic. teoretycznie moglbys zrobic np makro defn-unsafe ktore by dzialalo jak defn tylko np opakowywalo funkcje w try/catch i zwracalo wartosc nothing jak cos pojdzie nie tak, albo inna wartosc ktora bys traktowal jak error a ktora by przeciekala ale tak jak mowie jeszcze do zadnego sensownego wniosku nie doszedlem jak 100% fajnie by bylo obsluzyc wyjatki i to tak zeby potem kod nie wygladal jak potworek w ktorym glowna logika gdzies ginie. wiec narazie to takie luzne rozkminy ode mnie. jak ktos ma jakis ulubiony sposob obslugi wyjatkow to z checia uslysze 😉
wrap-unhandled-exception w ring, + raportowanie i sensowny blad 500
no to mozna powiedziec ze podejscie w stylu dire ktore zalinkowalem. ze masz zupelnie osoba funkcje do obslugi wyjatkow
inna sprawa ze uncaught exception handler to rejestruje z automatu w wiekszosci projektow jak juz nie ma jakiegos mechanizmu defaultowego we frameworku
+ obsluga bezposrednio na interopie, tak ze tylko interop musi sie wyjatkami martwic, reszta kodu czysta