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) 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).
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 >> >
