Would it be bad design to purposefully throw an error within a repeat to force an exit?

I am trying to simulate a Java WHILE loop within Developer without using Java services and thought that having a REPEAT ON SUCCESS would achieve that goal. When the condition is met, the error is thrown and the REPEAT is exited.

Thanks for your input.

Of course, I could just use EXIT and signal FAILURE – the simple approach!

What I usually do is this:

Label the repeat step 
Check the condition and if it is met: 
Use a Exit flow step and in the from box type in the label I gave the repeat step. 

This has worked very good for me. See if it’s what you are looking for.

One note to add to my preview post, my way assumes you want to continue with your flow process and not exit the service completely

Sometimes you do have to throw and error instead of using the Exit from loop/parent step.

If your exit point is enclosed in a try-catch sequence pattern and you use the Exit from loop in the try section the getLastError step in the catch section does not give the details of the error message. If you throw and Exception instead it will show up in the catch section. This is useful for a error trapping wrapper.

In fact, I also have quite similar problem…

we enumerate simple try catch blocks using sequences in flow services… If I want to throw an error in a child flow, so that the parent catches it and do error processing, I have to use “EXIT with signal FAILURE” option. This way the parent flow catches the child exception, and generates logging/email etc.

The only PROBLEM being any flow exits with signal FAILURE generates an email as if it was a service exception. The email goes to the person specified in watt.server.serviceMail, which is what I don’t want.

any way to circumvent it ?? A way, by which I can still exit from child flow as if an exception was thrown, and if such is caught in parent flow, doesn’t generate those annoying emails!!

Regards,
Saurabh.

Saurabh,

If you dont want your service to fail but want the parent to be notified of the error you will have to use some kind of error message string. This can have both expected and unexpected error messages trapped and passed to the parent flow.

I use a java service called throwError which just throws a ServiceException constructed from an error message string. In the following code snippet an expected error from step 1.1.5 will be caught in the 1.2 SEQUENCE block and any unexpected errors in the 1.1 SEQUENCE block would also be caught in the 1.2 SEQUENCE block. This situation is ideal candidate for a throwError kind of service. If I use an EXIT from $parent with failure step at 1.1.5.1 control does go to 1.2 but getLastError does not retrieve the error message.

1. SEQUENCE (Exit on Success)
   1.1 SEQUENCE (Exit on Failure)
   1.1.1 Your flow steps here
   1.1.2 …
   1.1.3 …
   1.1.4…
   1.1.5 BRANCH (check for error condition)
   1.1.5.1 throwError
   1.1.6 More flow steps
   1.1.7 …
   1.1.8 …
   1.2 SEQUENCE
   1.2.1 getLastError
   1.2.2 Assign lastError/error to a message string
   1.2.3 Exit with success

Thanks Rupinder, but this is not what I was aiming to solve.

Let me explain my problem more clearly !!

Lets assume there are 3 flow services : Parent1 invokes Child1, which in turn invokes Child2.

Here is the brief structure of how these flow services look likes :

Parent1

Flow Overview

    1    SEQUENCE  
1.1    MAIN: SEQUENCE  
1.11    INVOKE WriteToNohup  
1.12    INVOKE Child1  
1.13    INVOKE WriteToNohup  
1.2    SEQUENCE  
1.21    INVOKE getLastError  
1.22    INVOKE doErrorLogging  
1.23    EXIT '$flow'  

Child1

Flow Overview

    1    SEQUENCE  
1.1    MAIN: SEQUENCE  
1.11    INVOKE WriteToNohup  
1.12    INVOKE Child2  
1.13    INVOKE WriteToNohup  
1.2    SEQUENCE  
1.21    INVOKE getLastError  
1.22    INVOKE WriteToNohup  
1.23    EXIT '$flow'  

Child2

Flow Overview

    1    SEQUENCE  
1.1    MAIN: SEQUENCE  
1.11    INVOKE WriteToNohup  
1.12    INVOKE throwNullPointerException  
1.2    SEQUENCE  
1.21    INVOKE WriteToNohup  
1.22    EXIT '$flow'  

If I dont do a Exit “$flow” with Signal Failure, Child1 will never know if Child2 failed or not !!

And, if I use Exit “$flow” with Signal Failure, it will generate extra set of emails even though I do errorHandling in Parent1.

Hence, the search of a better solution error handling framework continues !!

Hope I am more clear this time in explaining.

Any suggestions or solutions are welcome !!

Regards,
Saurabh.

Why dont you use return status variables instead of Exit with failure. For example in Child1 and Child2 you can replace the Exit steps with a MAP that just assigns the lastError/error to an errorMessage variable. In the next step exit from flow with success.

In the calling service just call the child and then check for the errorMessage variable. If it exists you know that there was a failure and you can take any actions. And you avoided an error email being generated as you did not exit with a failure.

So Child1 and Child2 will look like this :

Child1

Flow Overview

1 SEQUENCE
1.1 MAIN: SEQUENCE
1.11 INVOKE WriteToNohup
1.12 INVOKE Child2
1.13 BRANCH
1.13.1 %errorMessage% != $null: throwError
1.14 INVOKE WriteToNohup
1.2 SEQUENCE
1.21 INVOKE getLastError
1.22 INVOKE WriteToNohup
1.23 MAP lastError/error to errorMessage and exit with success

Child2

Flow Overview

1 SEQUENCE
1.1 MAIN: SEQUENCE
1.11 INVOKE WriteToNohup
1.12 INVOKE throwNullPointerException
1.2 SEQUENCE
1.21 INVOKE getLastError
1.21 INVOKE WriteToNohup
1.22 MAP lastError/error to errorMessage and exit with success

Thanks for the quick response.

Yes, you are right, and I dont want it that way !!

I mean if child1 say invokes child2;3;4;5 , then I have to do branch after each invokes to the childs. Which I think is lot of overhead for resources/developer.

I guess, I am looking for a another way to throw an error in a flow service apart from “exit $flow with signal Failure” (which generates those extra emails)

The only problem to overcome is that webMethods doesnt allow java services to throw Exceptions. (apart from Server.throwError way which is no useful to catch or nest exceptions in our scenerio)

Hence, I guess, I am still looking for a better error Handling framework.

Regards,
Saurabh.