•The name of a declared WSDL fault and its associated data are unavailable to a <catchAll>. If you need access to this information, be sure to provide a specific <catch> with the fault name and fault variable.
•You can rethrow the fault that matched your <catch> or <catchAll> using the <rethrow> activity. The original fault data is rethrown, including the fault name and unmodified fault data.
•You are not limited to working with faults defined in a service's WSDL. You can define a <throw> activity to use a fault name and variable of your own creation.
•The standard runtime BPEL faults can occur due to errors in the design of a process (for example, having two receives executing concurrently on the same partner link and operation results in a bpel:conflictingReceive) as well as standard runtime errors. In general, it is not good design practice to catch these faults since they mostly represent errors that should be caught during simulation or testing of the process. There are some exceptions to this. For example, bpel:joinFailure is useful for identifying a situation where an activity does not execute due to its inbound links resulting to false.