On 03.07.2014, at 09:12, Konrad Windszus <konra...@gmx.de> wrote: > - The client can decide how to expose that error (whether just logging is > fine or something more obvious). This cannot be achieved by just setting up a > utility method, because that one does only see the null return value and not > the original reason for that.
Yes, but my question is whether there is any need to pass through the exception at all. > - Tracing problems during development is much easier (instead of looking at > the log I can see the full exception) You can debug exceptions inside the adapterfactories as well (after seeing them in the log). > - It allows to use it for something like validation in Sling Models How would that work? (I saw the reference earlier in the thread, but I don't know how you'd use adaptTo for validation and can't really imagine it's a good fit) > - It is less error-prone to the developers (you can easily forget to either > use the utility method or check for null) The null-returning method is out there, it cannot be changed to throw a checked exception (which is the only way to force handling for devs) > - In my regard in most of the cases if adaptation fails, there is something > wrong with the deployment (required bundles are not installed, components are > not running, ….) and I cannot reasonably work around that issue in the code > -> that calls for an exception It's not only exception, it's also a way to check if something is of a certain type (say adapting a resource to a resourcecollection). In this case an exception is not the right thing. 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 b) if it fails due to some actual exception, throw a runtimexception But not sure if that will work. Cheers, Alex
