Hi, On Thu, Jul 3, 2014 at 3:07 PM, Alexander Klimetschek <aklim...@adobe.com> wrote: > On 03.07.2014, at 13:58, Justin Edelson <jus...@justinedelson.com> wrote: > >> It won't work :) This is a hugely non-backwards compatible change. It >> happens to be binary compatible, but it is not semantically compatible >> (which is in some ways just as important). Callers of adaptTo() assume >> (because we have told them to assume) that null will be returned if >> the adaptation can't be done. We can't now start throwing exceptions. >> Callers won't expect this. > > There is a conflict with the other stated problem: that most callers don't > expect null either :) So if we change something, this will have an effect on > at least some callers either way, unless we add a new method with a different > semantic. > > But I'd say this is just adding complexity for no notable benefit. And just > improving the logging in case of exceptions in AdpaterFactories and > Adaptables or that static adaptOrThrow helper should be enough. > > Maybe some actual real world cases would help (i.e. no "Foo.class" > adaptations :). The only one I see is the Sling Models validation case as > originally outlined here [1] - but could you elaborate? I probably miss the > knowledge about sling models to see the issue.
Here's a sightly more real world case... let's say you have a call like this: Comment comment = resource.adaptTo(Comment.class); And for a Resource to be successfully adapted to a Comment, it must satisfy two criteria: 1) The resource type must be myco/comment 2) It must have a property called "commentType" (OK, this part isn't so real world). Right now, the caller has no way of knowing which of these critera wasn't met. That's IMHO the crux of this request - to provide a way for AdapterFactories to surface the failure reason back to the caller. Regards, Justin > > [1] http://markmail.org/message/lcujo4flwek3liez > > Cheers, > Alex
