Well, I'm not sure what's the best approach, but your suggestion would perhaps add more verbosity and so needs to have a reason.
Exceptions are not always necessarily a "bad" thing, they're just a language feature to indicate a different path of execution, so bubbling an exception to stop a service sounds reasonable and might be even a better approach because if you have very complex logic then you can just let the exception bubble up until it stop the service hence reverting all DB changes. I could be wrong or missing something of course, so opinions might enrich the discussion here. On Thu, Oct 18, 2018 at 11: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 : > > if (ServiceUtil.isError(result)) { > throw new > ExecutionServiceException(ServiceUtil.getErrorMessage(result)) > } > > Can anyone explain the intention behind that implementation ? > > I suppose that we need to catch any service call like : > > try { > serviceResult = run service: 'createQuoteAdjustment', with: > [*: quoteAdjustement, quoteId: quoteIdTo] > } catch (ExecutionServiceException e) { > return ServiceUtil.returnError(e.getMessage()) > } > > instead of : > > serviceResult = run service: 'createQuoteAdjustment', with: > [*: quoteAdjustement, quoteId: quoteIdTo] > > if (ServiceUtil.isError(serviceResult)) { > return serviceResult > } > > 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. > > What is the good way to handle service errors within services in Groovy? > > Thanks > > Gil