Hi Am 03.07.2014 um 11:10 schrieb Konrad Windszus <konra...@gmx.de>:
> > On 03 Jul 2014, at 10:50, Alexander Klimetschek <aklim...@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. > > I would be fine with that approach. So the only change is a clarification in > the Javadocs that adaptTo in fact may throw a RuntimeException (if the > AdapterFactory has thrown an exception) and also that AdapterFactory may > throw a RuntimeException. The question always remains: Do you expect the caller to handle this exception in some way or another ? Also, what exception can be expected by the client (you don't want to catch RuntimeException, do you ?) ? and what does it mean ? 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. Regards Felix > As Felix Meschberger already pointed out, neither the SlingAdaptable nor the > AdapterManager currently catch any exceptions so that would work already with > existing code and Sling Models could start right away throwing > RuntimeExceptions for validation purposes. > >> >> But not sure if that will work. >> >> Cheers, >> Alex >
