Within data services the Try Catch components are a much misunderstood pairing of workflow components. The following descriptions are taken from our course manual. First the Try Component
The Try component is part of a serial sequence (called the Try Catch Block) used for error handling within a work flow. In order to ‘Catch’ an error you must first set up the work flows that are to be protected through use of a Try Component. The component itself requires no configuration other than naming.
And now the Catch component
The ‘Catch’ component is the more complex part of the error handling. There must be at least one ‘Catch’ block but there may be more. In general you would define 1 ‘Catch’ block for each different behavior that can occur as a result of an error condition being encountered. There are two parts to the configuration of a ‘Catch’ component:-
Handled Exceptions: – Specifies the type of error that can be handled by this ‘Catch’
Exception Workflow:-Defines the workflow that should be run upon encountering this type of error
Catch components are like all other work flows, serial. This means that handling different kinds of errors in different manners is just a case of chaining catch statements to handle the different error types.
Lets have a look at this in operation, we will start with a workflow like this that merely copies files around. Now one thing that we need to be aware of at this juncture is that whilst the file_copy() function will report that an error has occurred the component itself will actually handle and consume that error meaning that any try-catch components will have nothing to handle in terms of errors. Instead the function returns a value to indicate whether the move was successful or not so we can use this to determine whether or not an exception needs to be raised. A little bit of house keeping first, I have created the following folders on my C: drive in the C:\Temp folder.
Inside the Source folder I have placed the following files:-
So lets start with designing a workflow that we can use to test this all out. We drag the following script components encircled by a pair of try catch component onto our canvas followed by a final script component. The canvas would look a little like this:-
As we have said earlier the try component needs no configuration, its just a statement of intent and so lets take a look at that catch component instead and how that is configured:-
In this instance, and to be honest in most instances, I’m not really interested in WHAT kind of error occurred, so I am saying whatever error occurs run the embedded workflow, in this case a script that copies a file called ‘error.txt’ to the destination folder which gives us a good visual indication that the error has been handled. The script looks like this:-
Now lets get to the meat of the script where we are actually looking to handle errors:-
As you can see in this script we are trying to copy a file that doesn’t exist from our source folder into our destination folder. If it doesn’t copy then we are raising an exception (remember that the file_copy function actually handles any exceptions internally and doesn’t bubble them up). What we should thus expect to see is that in our ‘dest’ folder because this operation will fail that the catch handler will out put an ‘error.txt’ file.
In addition to prove that the error was handled in a way that execution can continue let us define our last script which is executed after the main try catch block. This will look a little like this:-
and will copy the ‘Test2.txt’ file, which does exist into our destination folder. What this should mean is that after running the above workflow the following will happen:-
- An Attempt will be made to copy non existent file Test1.txt from our source to destination directory
- The above operation will fail and because of this fact the error handler will be invoked copying the file ‘Error.txt’ from the source to destination folder
- To prove that execution continues despite the fact that an error has occurred the final script will copy a file called ‘Test2.txt’ from the source to the destination directory
Lets try and run it:-
Despite the fact that we have a red cross at the top here you can see that our job has completed successfully. Lets take a look at the files that were output now:-
As you can see these are the files that we were expecting to see.
And Just to prove a point lets change our workflow to make it fail completely. If we copy the script located within the try catch and append it to BEFORE the try catch construct you should see the following workflow:-
The script can stay the same as that will fail. Before we run it delete the current contents of the Destination folder and upon running it you should see the following:-
So this looks to have failed completely, if you also check the destination folder you should see that this folder is completely empty meaning that all execution stopped after the first script failure. This was of course due to the absence of a surrounding Try-Catch construct.
Happy Catching my friends….