When to use Try/Catch?

It works fine. I use it all the time.

NOTE: although EXIT and Signal Failure works fine from within the “catch block” (ie. SEQUENCE EXIT ON DONE), pub.flow:throwExceptionForRetry does NOT. This can be a little confusing to some.

This should work fine. Check your SEQUENCE1 to make sure it is EXIT ON SUCCESS and not EXIT ON DONE. That could give you the behaviour you’re seeing.

Other things you may want to look at:

Is the EXIT (SIGNAL FAILURE) statement in your catch block the last statement?

Is this service being called by another service? If so, is it being called from within the “catch block” of the other service?

Is the service invoke that originally produces the error being called from within a transformer? (With some SP / Fix levels in IS 6.1 errors generated from services called within a transformer do not branch to the catch block properly. Furthermore, if the service that has the “erroring transformer” is called from something like an SAP listener (i.e. native code), it will take down the IS).

If you are still not having luck, upload a sample of your code, your IS version / SP level etc.

–jeff

Sorry - should have tested this first - this does not produce the behaviour you are seeing.

This also has no impact.

The other two scenarios that I describe might explain it…

If the catch block in the calling service does not have an exit signal failure, then this might explain it…

In this scenario, it will never even enter into the catch block…

Sorry for the erroneous previous post…

–jeff

Going back to the discussion on being in CAMP 1 or 2. My question is, if we catch an exception in child services and rethrow them what happens to the pipeline.

e.g.

parent service


try 
  A = 123;
  B = ABC;
  C = XYZ;
  CALL CHILD SERVICE1 (A, B)
catch

CHILD SERVICE 1(A, B)

t

ry 
  A = 321;
  B = CBA;
  1/ 0 
catch
  getLastError
  log the error
  throw with failure message;

So what happens to the pipeline. Will the pipeline variables A,B is modified to 321 and CBA in the parent service or will it stay as it was in the parent service before calling the child service which is 123 and ABC.

Ram Challuri

Neither…

In the sample that you gave A and B (and C for that matter) will have no values after the exception bubbles back up. Strings are not merged back into the parent pipeline until the successful execution of a code block (i.e. sequence, flow service etc.). Since A and B were defined in the “try” in the parent service, they will not have any value when you jump into the “catch”. Had you defined and initialized A and B before the “try” in the parent service, then they would have the values 123 and ABC respectively after the exception bubbled up (assuming you do not “exit signal failure” in your parent catch block).

BTW - why not just try this example for yourself to see what happens?

Sorry, but I have tested it my self and I know the answer for the above but my question was what should be the correct behaviour and what impact will that bebaviour have on using the try / catch block in the child service.

My finding are as follows.

If we use try / catch in the child service then

The parent pipleline values are not changed at the same time the lastError.pipeline.variable values are not changed either. where as if we don’t use the try / catch in the child serivce the parent pipleline remains the same but the lastError.pipeline.variable values will be latest.

More then often we would want to know exactly what was the last thing happened before the exception.

Ram Challuri

Hello,
Yes you are correct sonam. The way you have it explained in your response to my false statement was correct. The exit (at any point) forces an exit from an immediate sequence step (parent), loop/repeat (loop), or containing flow (flow). I am sorry to make such a mistake that would have people possibly doubt your positive, correct (structurally), and well thought suggestions.

The way which I showed is just one of many possibilities thanks to FLOW’s flexible SEQUENCE constructs and our creative ways. Good day.

Yemi Bedu

Thanks Yemi! Appreciate your clearing that up, bro. :slight_smile:

I think your approach is excellent. This is how I approach exception handling in other languages. I’ve seen code written from the standpoint that “professional” code never throws an exception, with the result that exceptions are eaten and lost during development so you don’t have a chance to correct them. I prefer to write code that breaks when it’s broken, to the extent of adding assertions liberally. I also feel that the more code that you write, the more chance there is of introducing an error. I really like to avoid “plumbing” as much as possible for this reason.

Also, there is more information returned by lastError than I am able to propagate in an EXIT step, so I feel that rethrowing an exception loses information (unless I’m missing something, which I probably am). Based on this, I would prefer to allow the exception to propagate up the stack unmolested to the top level (as you recommend, unless something thinks it can do something useful with it on the way).

Anyway, thanks for the excellent write-up. I’m going to include it in my team’s wm wiki.