There are two types of errors that occur, they depend on how the token called works.  Some are synchronous, and thus immediately error and throw a <status level="error">.

The other is asynchronous, like sending email, starting a workflow, adding a role (all the wrapped SOAP/REST calls) and if you look at the Local Variable browser in any token that supports them, you will see error.do-start-workflow, and so on.  Also, success.do-start-workflow variables.

They are empty if no messages

Thanks!

For the synchronous cases Geoffrey refers to, I already have standard code in otp/itp (that handles some known issues with status “xx” and convert to status “yy”)

Often this is error to fatal or error to retry, sometimes error to success (depends on the failure scenario)

For async cases, one first has to verify that the other side is going to give you an honest response you can trust. If this is the case, then parse the the local variable and do something with that.

There is a third type of error, which is easy to miss. It is a variant of the synchronous case.

Sometimes single thing fails, but then continues on processing subsequent logic (which might do unpredictable/unwanted things lacking a sensible input from the failed rule.).
You can see this type of error in trace by a "Error in vnd.nds.stream:" type message

For synchronous but otherwise uncatchable errors, I use the following approach.

1. Set a named flag (operation property) to indicate that the next portion of code must succeed or execution should stop.
2. Policy that could do something hard to catch. like lookup a mapping table that might not actually exist in the system (yet)
3. Clear operation property flag set in step 1.
4. Add conditions to subsequent related polices to detect this operation property that is set in step 1. Logic can vary.
 

During normal operation, the flag will always be cleared, only when the (normally uncatchable) error occurs, will the flag have not been cleared.

Thanks.