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