I just came up with another example from CQ: In Sightly you can instantiate a model via the use API [1]. Since that logic will first try to adapt from Resource then from Request and as fallback tries to instantiate the class leveraging the default constructor, you won’t get any exceptions in case required properties cannot be injected (and the default constructor is available).
In most of the cases instantiating the class via the default constructor is not the right thing to do, because if the class is annotated with @Model and instanciation fails that should be propagated to the user. In this case it defers the error message to an NPE being thrown whenever someone is trying to access the field (which was not instantiated because the object was not created with Sling Models but as a regular POJO with no injections at all). That takes quite some time to figure out during development, that actually Sling Models cannot really instantiate the class and therefore the Sightly Use Extension will instantiate it as simple Pojo. That would not have happened, if Sling Models would be allowed to throw exceptions in case the instanciation was not successfull! [1] - http://docs.adobe.com/docs/en/aem/6-0/develop/sightly/use-api-in-java.html#Alternatives%20to%20WCMUse On 07 Jul 2014, at 18:42, Carsten Ziegeler <cziege...@apache.org> wrote: > 2014-07-07 18:29 GMT+02:00 Konrad Windszus <konra...@gmx.de>: > >> Provide a meaningful error message to the author or at least to the >> developer (leveraging the WCMDeveloperMode). By meaningful I don’t talk >> about something hidden within the logs. >> > > This doesn't really convince me - the same argument would hold true for > every API where the exception (cause) is logged, but the method just gives > back true/false,object/null. Even for APIs throwing an exception it might > be hard to get a meaningful message to developer. So this isn't done for > other APIs, why should we do it differently for adaptTo? > In addition, if you have a lot of client code using the adapter pattern, > then you end up in converting the exception to a meaningful message in > various places. > > It would be so easy to let the adapter factory do a meaningful log > statement and there are tools/apis to pick up this log message and display > it to the dev without requiring the developer to go to the log > > Carsten > > > >> Konrad >> >> On 07 Jul 2014, at 18:27, Carsten Ziegeler <cziege...@apache.org> wrote: >> >>> 2014-07-07 18:14 GMT+02:00 Justin Edelson <jus...@justinedelson.com>: >>> >>>> Hi, >>>> >>>> >>>> I found a more concrete example in the AEM codebase (so apologies to >>>> the non-Adobe people on this thread who will just have to take my word >>>> for it). The adapter factory which adapts Resources into Scene7 "set" >>>> objects makes a number of validations before returning a non-null >>>> result: >>>> 1) Is the Resource an Asset? >>>> 2) Does the Asset represet a Scene7 set? (which is done by looking at >>>> a property) >>>> 3) Does the requested set class correspond to the set type of the Asset? >>>> >>>> >>> But again, what different action would a client take depending on the >> error >>> condition 1, 2 or 3? >>> >>> Carsten >>> >>> >>>> Regards, >>>> Justin >>>> >>>>> >>>>> Cheers, >>>>> Alex >>>>> >>>> >>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >> >> > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
