Errors

Handling errors in a distributed system is typically complex. Infinitic simplifies this by automatically tracking error chains and allowing you to handle errors directly within the workflow.

Types of Exceptions in Workflows

The only exceptions that can be thrown inside a workflow are categorized as follows:

Due to Task failures

• TaskFailedException: Thrown when accessing the result of a failed task.
• TaskTimedOutException: Thrown when accessing the result of a timed out task.

Due to Workflow Failures

• WorkflowFailedException: Thrown when accessing the result of a failed workflow, due to a failed task or another failed workflow.
• WorkflowExecutorException: Thrown when accessing the result of a failed workflow, due to an error in its implementation.
• WorkflowTimedOutException: Thrown when accessing the result of a timed out workflow.
• WorkflowCanceledException: Thrown when accessing the result of a canceled workflow.
• WorkflowUnknownException: Thrown when accessing the result of a unknown workflow.

Errors Due to a Task Failure

TaskFailedException

This exception is thrown when a workflow attempts to access the result of a failed task. From a workflow point of view, a task is failed after all the automatic retries failed:

The TaskFailedException can also occur when waiting for the result of a task that was previously dispatched asynchronously:

A TaskFailedException has detailed information about the failed task:

The TaskFailure object describes each attempt to execute the task and has the following properties:

The GenericException class is used to store the details of the original exception:

The GenericException class provides two methods for accessing custom properties of the original exception:

• the getCustomProperties() method returns a map containing all custom properties of the original exception.
• the getCustomProperty(String name) method retrieves a specific custom property by its name, provided it was successfully serialized and deserialized.

TaskTimedOutException

This exception is thrown when a workflow attempts to access the result of a timed-out task:

A TaskTimedOutException has the following properties:

Errors Due to a (Child) Workflow Failure

WorkflowFailedException

This exception is thrown when a workflow or a client attempts to access the result of another workflow that failed due to the failure of a task or another workflow.

For instance, this exception throws in the parent workflow of a failing child workflow:

Or if a client waits synchronously for the result of another failing workflow:

A WorkflowFailedException has the following properties:

WorkflowTimedOutException

This exception is thrown when a workflow or a client attempts to access the result of a child workflow that timed out. The timeout duration is specified in the interface of the Workflow:

A WorkflowTimedOutException has the following properties:

WorkflowCanceledException

This exception is thrown when a workflow or a client attempts to access the result of a child workflow that has been canceled.

A WorkflowCanceledException has the following properties:

WorkflowUnknownException

This exception is thrown when a workflow or a client attempts to access the result of a child workflow that is unknown - this can happen when targeting a workflow by its ID.

A WorkflowCanceledException has the following properties:

WorkflowExecutorException

This exception is thrown when a workflow or a client attempts to access the result of a workflow that failed due to an error in its own implementation.

A WorkflowExecutorException has the following properties:

Try/catch in workflows

Use try/catch of DeferredException in workflows if you want to ensure that the workflow continues to run even if a task or another workflow failed:

String str;
try {
    // synchronous call of HelloService::sayHello
    str = helloService.sayHello(name);
} catch (TaskFailedException e) {
    // react to the task failure
    ...
}

// synchronous call of HelloService::sayHello
val str = try {
    helloService.sayHello(name)
} catch (e: TaskFailedException) {
    // react to the task failure
    ...
}

Remember, for expected failures, it's a better practice to handle them within the Service and return a status object.