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

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

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

> 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

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

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

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

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

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

> 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

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

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

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

+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

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

+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

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

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

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

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

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

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