Handling Exceptions Using the Catch Activity

Programming and application errors can be anticipated, detected and resolved. Error handlers are the ones which are tasked to identify the errors. It can either recover from the errors without the need to terminate the application or keep the error report to a file. Then it will terminate the affected application.

If these application errors are detected on an early stage, it lessens the effort of reworking. Time, cost and resources can also be saved upon the detection.

When an unhandled exception occurs, an activity receives control of execution. This activity is called the Catch activity. Exceptions are handled one by one, or you can specify to handle ALL exceptions. You can have more than one exception, but you must be sure that each Catch activity handles a unique exception type.

If you wish to perform to handle the exception, the Catch activity allows you to transition to activities. You cannot transition back to the main execution track from the Catch track. Transitions are permitted between Catch tracks within an exception scope.

But if you want to throw the exception caught again, you may use the Rethrow activity. This activity is used to propagate the exception to the higher level.

A try/catch block allows you to try to perform an action, or in the case of TIBCO, an activity. If an exception occurs, it will catch the exception and lastly, deal with the exception gracefully rather than crashing the application.

You can create a Try/Catch block in TIBCO with the use of Groups. The Catch and Generate Error activity must be put inside a Group, and set the action into “none”. This is used for grouping without the loop. With only one condition for the group, this will allow you to catch any error that occurs inside of the group. You don’t need to catch errors in each activity individually.
Error data will be available to activities that has executed after the error transition. The error data can be found on two types of process variables, the $_error process variable and the activity error variables ($_error_). After an error had occurred, this can be found on the Process Data Panel.

The $_error process variable will show the ErrorReport complex element that contains the schema depending on the activity that throws an error. This is the error’s general information like StackTrace, Msg, FullClass, etc. The $_error process variable is also useful in an error-handling procedure because you can map data from this process variable into input items for activities in your error-handling procedure.

On the other hand, the $_error_ shows the error output schema. Remember that each activity has one or more predefined error schemas. You can see these schemas on the activity’s Error Output tab. These are represented as a choice element. The $_error_ process variable is made and supplied with the error data, when an error is encountered.