> On 03 Apr 2016, at 10:49, Thomas Mortagne <thomas.morta...@xwiki.com> wrote:
>
> You will start catching when you want to deal with errors (before that
> the Velocity macro will deal with it for you automatically) and it
> does not really cost much more lines to deal with errors that way than
> using checking for null return (for method that actually return
> something that could be null to indicate errors) and getLastError()
> concept like we do now.
Yes, and in addition it will prevent side effects. Right now if you call a
method than can fail and you don’t check the result, the next lines will be
wrong and can even cause problems.
For example:
{{velocity}}
#set ($someVar = $someobject.somethod()) ## result of server-side computation
that failed and return null
#set ($somedoc = $xwiki.getDocument("${someVar}-whatever”))
$somedoc.save()
{{/velocity}}
If someobject.somemethod() throws an Exception then there’s no risk of causing
side effects.
Thanks
-Vincent
>
> On Sun, Apr 3, 2016 at 12:19 AM, Eduard Moraru <enygma2...@gmail.com> wrote:
>> +0
>>
>> I can`t help but feel we are stretching Velocity more than what it was
>> built for and we might end up with a more verbose and spaghetti code than
>> what we would have liked (and than we currently have).
>>
>> As long as we try not to abuse it, I guess we can see how it goes.
>>
>> Thanks,
>> Eduard
>>
>> On Sat, Apr 2, 2016 at 11:59 AM, Vincent Massol <vinc...@massol.net> wrote:
>>
>>>
>>>> On 01 Apr 2016, at 23:04, Sergiu Dumitriu <ser...@xwiki.org> wrote:
>>>>
>>>> I think that it's a good idea for script services to throw somewhat
>>>> expected exceptions, signalling invalid usage attempts (user not
>>>> authorized, wrong arguments...) that would then be caught in Velocity.
>>>> But deeper platform issues (DB errors, unexpected NPE, OOM...) should be
>>>> handled outside the user's code itself, at the skin level (view.vm).
>>>
>>> Sure, that’s the point. The scripts can decide to catch or not (ie. to
>>> handle or not). If not then it’s caught anyway at the level of
>>> MacroTransformation (for macros) or at the level of contentview.vm. In the
>>> majority of cases there isn’t much that the script can do and it shouldn’t
>>> catch anything (it should catch only if it can handle it, i.e. do something
>>> with the exception).
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>>> On 04/01/2016 05:45 AM, Vincent Massol wrote:
>>>>> So far we have the following devs who agree:
>>>>> - thomas
>>>>> - marius
>>>>> - vincent
>>>>>
>>>>> What about Edy, Sergiu and the others?
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>> On 31 Mar 2016, at 14:17, Vincent Massol <vinc...@massol.net> wrote:
>>>>>>
>>>>>> Guys, I’d like that we progress on this.
>>>>>>
>>>>>> I didn’t get any agreement or disagreement to this proposal.
>>>>>>
>>>>>> Any take?
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>
>>>>>>> On 18 Jan 2016, at 11:03, vinc...@massol.net wrote:
>>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>> After a lot of thinking and experimentation (see the thread’s
>>> details), I have found that this first proposal is not a good idea. I’m
>>> thus proposing to replace it with the following best practice:
>>>>>>>
>>>>>>> * Let our script services generate exceptions
>>>>>>> * If the velocity scripts with to handle the exceptions, then they
>>> should use the #try() directive. If they don’t want to, they don’t have to
>>> do anything since the MacroTransformation or the template (contentvars.vm
>>> for example) will catch it and display it to the user.
>>>>>>>
>>>>>>> More precisely I’m proposing that:
>>>>>>>
>>>>>>> * Existing Script APIs in Java should not be modified as that would
>>> break backward compatibility. New signatures can be added and old one
>>> deprecated and moved to the legacy modules. After new signatures have been
>>> introduced, existing velocity scripts can be updated to use the new
>>> signatures and to use the #try directive if needed.
>>>>>>> * New Script APIs must use the new best practices (if agreed :)),
>>> i.e. throw Exceptions, and new velocity scripts must use the #try()
>>> directive if they need to handle exceptions.
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Vincent
>>>>>>>
>>>>>>>
>>>>>>> On 14 Jan 2016 at 17:51:04, vinc...@massol.net (vinc...@massol.net
>>> (mailto:vinc...@massol.net)) wrote:
>>>>>>>
>>>>>>>> Hi devs,
>>>>>>>>
>>>>>>>> Right now our strategy is for script services and script APIs in
>>> general to catch exceptions, store them and offer a getLastError() method
>>> to get them (see
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPractices
>>> )
>>>>>>>>
>>>>>>>> However it would be much nicer to:
>>>>>>>> * Let our script services generate exceptions
>>>>>>>> * Offer a velocity script service to get the last exception raised
>>> by a java call from velocity
>>>>>>>> * Implement this uberspector to catch the exceptions and to set them
>>> in the execution context
>>>>>>>>
>>>>>>>> That should be quite easy to implement IMO.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>> PS: This is http://jira.xwiki.org/browse/XWIKI-2374
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
