Am Freitag, den 19.10.2007, 14:53 +0200 schrieb Bertrand Delacretaz: > > ...I would suggest, that all > > methods allowed to throw checked exceptions should throw SlingException.... > > The downside is having to rethrow exceptions which the implementation > gets and which are not SlingExceptions. > > What's the upside, in your opinion? > > (I'm not being ironic, it's really a question that no one answered in > a satisfactory way for my pragmatic brain until now)
I am ok with the question - I asked it to myself, too. But then, here is why I propose this: We define an API for the Sling realm which has its own exception hierarchy rooted at SlingException (extends ServletException). We define an API for Sling (or microsling for that matter) applications, so the most natural thing counting these two together is to require SlingExceptions to be thrown. So applications may catch Exceptions within the core domain model of the API. So I think, that trying to unwind exceptions would involve knowledge of the implementation (e.g. interpreting RepositoryException (or worse SqlException) ) upfront, would link the application into the implementation too much. So rather, I would suggest to define more specific exceptions if required (e.g. if we think Resource resolution failure should be better visible, define a ResourceResolutionException extends SlingException). Another point is, that whenever a method is declared throws Exception I am force to catch(Exception), which is something a definitely do not like because I might want to let RuntimeException pass through. Otherwise I would also be required to declare throws Exception and may not even be able to describe what exact exception I am expected to throw ... Moreover, requiring specific API domain exceptions also requires the implementor (not the user) to think about the possible problems that may occurr. There may be more reasons, which do not come to my mind currently. But I know (unfortunately I do not have the book handy right now) that Josh Bloch wrote about this issue in his seminal work Effective Java [1]. Regards Felix [1] http://www.amazon.com/Effective-Java-Programming-Language-Guide/dp/0321356683
