Thanks Jacopo and Taher for your answers. I understand now the goal of this and will try to use it to allow less verbosity in service error handling management in Groovy DSL.
Indeed, in a way, each service using groovy should throw ExecutionServiceException that should be managed within the service engine itself. In that way, there won't be needed systematic test against service return in groovy and that is a good thing. Gil Le dimanche 21 oct. 2018 à 08:02:35 (+0200), Jacopo Cappellato a écrit : > On Thu, Oct 18, 2018 at 10:45 AM Gil Portenseigne < > gil.portensei...@nereide.fr> wrote: > > > Hello ! > > > > While we are working on Groovy migration at Nereide, we figured out that > > using ‘run service’ DSL method instead of returning the errorMap, a > > ‘ExecutionServiceException’ is thrown > > [...] > > I wonder if exception management is more costly than simple return. > > May the GroovyEngine should handle the exception ? I do not grasp yet > > the benenit of this implementation. > > > > Hi Gil, > > if I recall correctly, the original goal was to implement a behavior > similar to the default one of Minilang: if an error is thrown during the > execution of the "call-service" directive in Minilang then the script > execution is halted (see the definition of the property "break-on-error"). > > I hope it makes sense, > > Jacopo
