On 03.07.2014, at 12:19, Felix Meschberger <fmesc...@adobe.com> wrote:
>>> I guess it would make sense to have adapterfactories et. al. to work like >>> this: >>> a) if it is not of the desired type, i.e. cannot semantically be adapted, >>> return null > > example: resource.adaptTo(Node.class) for a resource not backed by a JCR Node > instance. > >>> b) if it fails due to some actual exception, throw a runtimexception > > example: resource.adaptTo(Comment.class) when the required data to setup the > Comment instance cannot be read from persistence or the data is inconsistent > and thus a consistent Comment instance cannot be provided. This is on the edge - could also be seen as a). To me b) would be if while creating/reading that Comment instance, some unexpected JCR RepositoryException is thrown (i.e. network failure). > If handling just is catching and logging, there is no use in throwing in the > first place — better immediately log and return some decent value that client > can cope with, which in the case of adaptTo is just null (as documented). > Plus: the boiler plate to catch and log is more complicated and convoluted > than the boiler plate for the null check. If it's a runtime exception, you don't have to catch it immediately. In a request context, the sling request execution would catch & log that exception for you, thus by default the request would fail, which makes sense in case of an unexpected error like b). But if you want, you could catch it too (i.e. would need to be documented what kind of RuntimeException) and do things like retry etc. (although generally b) is something you can't do much about and almost always would make the whole request or operation fail). Cheers, Alex
