Hi Am 03.07.2014 um 12:29 schrieb Konrad Windszus <konra...@gmx.de>:
> The AdapterFactory should clearly state, which RuntimeExceptions are thrown > under which condition. You know in most of the cases, which AdapterFactory is > responsible for your adaptTo-method (or you should be able to find out with > the web console) I see. How about thus adding an annotation for the AdapterFactory to declare the exceptions thrown so the web console could expose this information as well — in the same way as there is the annotations to declare the adapters and adaptables. > Handling in some cases is more than simple logging. The AEM6 > WCMDeveloperModeFilter is a good example for another error treatment > (catching the error within a servlet filter and then exposing via the Web UI). Good point Regards Felix > > On 03 Jul 2014, at 12:19, Felix Meschberger <fmesc...@adobe.com> wrote: > >> 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 >>> >> >
