. This is suitable when you foresee that the error might occur and you want to use a data decision step to branch the process based on the normal process flow.
Throw a fault
. This is suitable when the only appropriate response to the error is to pass the error up to the caller or log the error and suspend the process. For example, if you attempt to access a web service that responds with the HTTP status code, 403 Forbidden, it indicates that the service understood the request but refuses to take any action, because access is denied. Throwing a fault is normally the best option to handle this error because you are unlikely to resolve it in the normal process flow.
Throw Step Usage
When you add a Throw step to a process, the error information is propagated by the Throw step. This allows you to catch the fault when you call it, for example, through a Subprocess step.
The name must be a string value.
Throw is a terminating step so it does not support any outbound links.
A Throw step can be used to rethrow information caught using a fault handler. In that case, the payload for the step is a faultInfo element that contains the parameters returned by the service, service connector, or SOA connector.
You can also use a Throw step to construct specific fault information that you want to use as part of your process.