Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Vincent Massol]

Hi,

This wasn’t a vote but everybody who replied agreed (Marius, Thomas, Vincent, 
Sergiu, Edy wasn’t thrilled but was ok too ;)), so let’s do it!

I’ve now documented it at 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPractices

So please make sure you code your Script Services so that they throw exceptions 
now :)

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

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Vincent Massol]

> On 03 Apr 2016, at 10:49, Thomas Mortagne  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  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  wrote:
>> 
>>> 
 On 01 Apr 2016, at 23:04, Sergiu Dumitriu  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  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 

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Thomas Mortagne]

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.

On Sun, Apr 3, 2016 at 12:19 AM, Eduard Moraru  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  wrote:
>
>>
>> > On 01 Apr 2016, at 23:04, Sergiu Dumitriu  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  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
>> >>
>> >
>> >
>> > --
>> > Sergiu Dumitriu
>> > http://purl.org/net/sergiu
>> > ___
>> > devs mailing list
>> > devs@xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>> ___
>> devs mailing list
>> devs@xwiki.org
>> 

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Eduard Moraru]

+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  wrote:

>
> > On 01 Apr 2016, at 23:04, Sergiu Dumitriu  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  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
> >>
> >
> >
> > --
> > Sergiu Dumitriu
> > http://purl.org/net/sergiu
> > ___
> > devs mailing list
> > devs@xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Vincent Massol]

> On 01 Apr 2016, at 23:04, Sergiu Dumitriu  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  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
>> 
> 
> 
> -- 
> Sergiu Dumitriu
> http://purl.org/net/sergiu
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Sergiu Dumitriu]

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

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


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Thomas Mortagne]

+1 it certainly makes writing script services much easier (and harder
to ignore proper error handling on script side :))

On Thu, Mar 31, 2016 at 3:20 PM, Marius Dumitru Florea
 wrote:
> +1 for throwing exceptions in script services and using #try to catch them
> if we want.
>
> Thanks,
> Marius
>
> On Thu, Mar 31, 2016 at 3:17 PM, Vincent Massol  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
>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Marius Dumitru Florea]

+1 for throwing exceptions in script services and using #try to catch them
if we want.

Thanks,
Marius

On Thu, Mar 31, 2016 at 3:17 PM, Vincent Massol  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
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Vincent Massol]

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

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[vinc...@massol.net]

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

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Paul Libbrecht]

Vincent,

is there not a need to version the legacy?
I know of no installation that does not have the legacy jars and I
wonder if this could not be better controlled so that installers can
actively get rid of the legacy.

paul

> vinc...@massol.net 
> 18 January 2016 at 11:03
> 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
>
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> vinc...@massol.net 
> 14 January 2016 at 17:51
> 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

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs