Why do you want to bind incorrectly
About the WebSphere Adapter error binding principle and application, you can participate in another article by the author (link below: http://www.ibm.com/developerworks/cn/websphere/library/ techarticles/0912_wuwei_adaptererror/), in this article, the author will briefly describe why the customer needs an error binding, the error bindings that are currently supported by WebSphere Adapter, and the meaning and implementation of custom error binding.
Error binding is a mechanism provided by WebSphere Adapter to deal with business logic exceptions, which distinguishes run-time exceptions from business logic exceptions, and provides more meaningful error data to the caller of the application system through this error handling mechanism.
The meaning of error binding is that it can provide customers with a mechanism to distinguish between run-time exceptions and business logic exceptions, and the user does not need to check for lengthy Run-time exception logs when handling business logic exceptions, but rather handles the returned error business object directly. Based on this mechanism, users can greatly reduce the cost of handling exceptions, and the error data returned is more specific and more meaningful.
The working mechanism of the error binding
In this section, we will use WebSphere Adapter for JDBC as an example to briefly review the process of error binding, see Figure 1 below:
Figure 1. Error binding flowchart
As shown in the figure above, when the WebSphere Adapter encounters an exception (Exception), WebSphere Adapter first invokes the error selector (Fault Selector) to determine if this exception is an error that is supported by WebSphere Adapter. If not, no processing is done, and if so, the error selector is invoked to generate the corresponding error name (Fault name). It then finds the corresponding error binding type (Fault Binding type) based on the wrong name, and finally calls the wrong binding type to generate the corresponding error data (Fault data) and returns the error data to the caller.
This shows that the user can customize the error selector to determine what type of exception should be handled as an error, and can also customize the error binding implementation to place custom error messages in the wrong object.