You're missing my point. How would your Sightly script indicate that a RuntimeException should be thrown in the first place? Or are you suggesting that Sightly assume that this is always the case?
On Mon, Jul 28, 2014 at 12:07 PM, Konrad Windszus <konra...@gmx.de> wrote: > In my regard in this case a RuntimeException would be fine. That would be > propagated correctly to the script level. > So whenever a model class has the model annotation and something went wrong > during the injection throwing a runtime exception would be correctly > propagated and no other option would be tried (even when using Sightlies Use > Extension) > > On 28 Jul 2014, at 18:03, Justin Edelson <jus...@justinedelson.com> wrote: > >> Hi Konrad, >> In this case, I don't see how any of the options in this thread would >> actually help because the code which calls adaptTo() is not under your >> control. So there would be no way for the caller (i.e. your Sightly >> script) to indicate that such an exception should be thrown. >> >> Regards, >> Justin >> >> On Mon, Jul 28, 2014 at 11:44 AM, Konrad Windszus <konra...@gmx.de> wrote: >>> 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 >>> >