Designer 10.3 now provides the following new flow steps for in the palette view and context menu:
TRY-CATCH,
TRY-FINALLY,
CATCH, and FINALLY which is a cool feature and saves time and several clicks of a button.
The functionality works fine, however, the Exit on property is set to FAILURE (unchangeable) for CATCH and FINALLY step. Is this is a UI typo error or any specific reasons? Attached screenshots.
Also, I could not find any trace of this in the docs “10-3_Service_Development_Help.pdf”
For try, catch, and finally, exit-on failure is the only permitted value. There was some internal debate as to whether we should not show the value at all, or to show it indicating that it was a fixed value. The rationale is explained in the doc, which will be released as a doc update in the near future.
We decided to implement the semantics of Java try-catch-finally as closely as possible, which required that exit-on be limited to failure.
Is there a plan to bring together these 2 styles of exception handling in flow services? In the sense of a “migration” tool from the old style to the new one.
Of course, there is the possibility of leaving this to each client and they can do it:
Hi Vlad,
There are tens of thousands of customer Flows out there so we made every attempt to preserve old behavior. Old Flows work unchanged. In fact if anyone finds an old Flow that works differently it should be reported as a bug. The challenge was to add in the new behaviors in a way that preserve the old behavior as well.
I think there probably are typical old-style sequence patterns that could be automatically converted. The first challenge is to catalogue the various patterns and then design a tool that recognizes the various patterns.
We are working on a doc update that includes a lot of details, including information about comparability.
Interesting. I’d be interested in understanding a bit of the debate about why these were introduced at all. I can honestly say that I’ve never once thought “I wish there was a finally construct” when writing FLOW. The try/catch structure has been wholly sufficient. But maybe I’m missing something.
What are others thinking about doing with this that cannot be done now? Is it purely a readability concern? Indeed, I’m trying to think about a scenario where FINALLY would be useful, and could not be handled in the “traditional” catch sequence.
one thing might be connection handling, i.e. SFTP connections.
Login will be handled in its own try/catch (for the case it fails) and then the sessionkey is propagated to the get- and put-services et al.
In the Catch section the session can be closed on any processing error, for success it should be closed in the Try section.
But to be sure, that it has been definitely closed without leaving open threads you can close it in the Finally section again.
I’ve given myself a head smack for my “duh” moment. I got so wrapped up in thinking about “I can do this now with the existing sequence structures” I forgot about the raison d’etre of finally – don’t repeat yourself.
FTP/SFTP/SSH connections are indeed the scenario I had in mind – and we use the try/catch sequence structure to close on error, as you describe. We can now put this, and other “clean up” code, in the finally block instead of the same steps in 2 places.
Back when the Integration Server was first created by webMethods the company, flow was meant to be a tool that could be used by non-developers and therefore these strange flow steps were created to make it graphically intuitive. Sadly setting up basic control flow steps for a programmer didn’t make intuitive sense and hasn’t for a long time. So I welcome this improvement.
I personally would like to see if-then-else implemented too.
This reminds me of Dan Green’s old, old post where he stated “Without sounding melodramatic, Java developers can significantly increase a project’s time-to-market and ruin your ROI.”
It is a delicate balance SAG needs to maintain with FLOW. Add useful features but don’t get too much like Java.
There is no try/catch/finally construct in 9.8. It can be simulated using various combinations of exit-on DONE, exit-on FAILURE, etc. Since there was no standardized way to perform the try/catch/finally pattern, it was difficult to easily determine the implementer’s intent when viewing a Flow. It was also very difficult to implement nested try/catch blocks. The 10.3 release added formal definitions for try/catch/finally in order to address these issues.
Thank you for the quick response and clarifying the doubt.
One more thing: since we cannot edit the “Exit on” property from CATCH/FAILURE , how will it work? As in the previous versions, we used to edit/provide in, say, CATCH - Exit on: DONE or FAILURE - Exit on: DONE. Do we have to use the previous methods to do that?
The goal with Flow try/catch/finally is to capture the essence of Java try/catch/finally while not compromising the overall nature of Flow.
The Java try, catch, and finally blocks execute until there is a failure; thus the Flow try, catch, and finally blocks are hard-wired to do the same.
There is no similar idea within Java, execute until complete, but this can still be accomplished with sequence exit-on DONE, though there is no catch or finally possible when using sequence. Any Flow that used to work will still work without change; the TCF behavior is strictly additive.
Below are few scenarios where Finally block can be used :-
To close FTP session opened in try block.
For service retry scenarios.
If it is a trigger service, withDB operations, and if DB resource is unavailable, use finally block to suspend trigger. In This case, we need to have a monitoring service in trigger to monitor for DB resource.
