Groovy DSL runService Exception Management ?

[Gil Portenseigne]

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

[taher]

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
<[hidden email]> 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

[Jacopo Cappellato-5]

On Thu, Oct 18, 2018 at 10:45 AM Gil Portenseigne <
[hidden email]> 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

[Gil Portenseigne]

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 <
> [hidden email]> 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