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

Reply via email to