Description
This activity tries to execute the steps defined in the try block (for example, selecting an element, converting data types, etc.). Exceptions that might occur while performing those steps can be caught in the catch block so that the execution of the workflow continues afterward.
Properties
Analyst
- Display Name:The title of the activity that will be displayed in the workflow.
Example
Often, you have steps in your process that will not be executed successfully every time, because exceptions occur during the execution of the activity. One reason for this might be that you deal with user input. Sometimes, that input data will be invalid (for example, data type conversions will fail due to false input).
With the Try Catch Activity, you can handle such cases. The Try Catch Activity consists of two main blocks:
- Try block: Place those activities here, where known exceptions occur that should be handled.
- Catch blocks: In the catch block, you specify the exceptions you want to catch. You can catch one or many exceptions. Within each catch block, you can specify your custom logic that should be executed if this specific exception. Typically, you start with logging your exception, so that it shows up in the log of the task even though the execution was continued.
You could also define some additional logic in the finally block. This block is always executed, independent of whether any catch block was reached (it would typically contain steps that should be performed either way).
Let's have a look at one simple example. We use the Rename File Activity to rename a file and we want to handle possible exceptions. Therefore, we place the Rename File Activity in the Try block.
Suppose, we want to catch three specific exceptions
- System.IO.FileNotFoundException (triggered if the source file does not exist)
- System.IO.PathTooLongException (triggered if the complete path exceeds 260 characters)
- System.IO.IOException (triggered if any exception occurs while accessing files))
Inside each catch block, we log the error message using the Write Log Activity. You can also use the exception argument to access specific information (for example, inner exceptions). In addition, the Boolean variable fileWasNotRenamed is set to true, since we might want to differentiate later in the process between cases where the file was renamed successfully and cases where the renaming failed:
Tips and Tricks
- Instead of using the Try Catch
Activity, you could often use the Continue On Error option provided by many
activities. This approach has, however, some drawbacks:
- You won't see exceptions in the log, because they are not logged.
- You catch all exceptions by default (makes the debugging of your process harder).
- You might forget where you used this option and since no exceptions are shown, you will spend unnecessary time searching for the error(s) in your process (makes the debugging of your process harder).
- You cannot differentiate between multiple exceptions and handle them differently.
- You should not place complex or error-prone process steps within your catch blocks (otherwise another, a new exception might occur in the catch block that you did not handle).
- Whenever you catch multiple exceptions, you should begin with the most specific exception and place the most general exception in the last catch block (for example, Exception which will catch all exceptions). Otherwise, you'll never enter the subsequent catch blocks because all exceptions are already caught by the generic base class.
- If you want to place more than one activity in the try or catch block, it is usually a good idea to drag and drop a flowchart in the corresponding block first and place all your activities inside this flowchart
- You can use the Throw activity with the exception argument as an input to re-throw the exception in the catch block