234

Developing Client Applications to Use a Web Service

/order_not_found_exception.jsp

Code Example 5.16

Using the Servlet Error Mechanism

Notice that using the servlet error mechanism in this way tightly binds the

Web application client to the service. If the service changes the faults it throws, or

any of the fault parameters, the client is directly affected.

E

Client developers should isolate service specific exceptions as much as possi 

ble by wrapping them in their own application specific exceptions to keep the 

client application from being too closely tied to a service. This is especially 

important when the service is outside the control of the client developer or if 

the service changes frequently. A client may require refactoring when a service 

changes because the stubs and supporting Java object representations of the ex 

ceptions were generated statically.

Client developers may also generalize exception handling and instead handle

all exceptions in a single point in the application. Keeping exception handling to

one place in an application reduces the need to include code for handling excep 

tions throughout the application.

try {

OrderDetails od = stub.getOrderDetails(orderId); 

} catch (OrderNotFoundException onx) {

RuntimeException re= new RuntimeException(onx);

}

Code Example 5.17

Generalized Exception Processing

In Code Example 5.17, the exception thrown as a result of the Web service

call is set as the cause of the runtime exception. This technique, known as chain 

ing exceptions, produces a better stack trace and helps to more clearly display the

root cause of the exception. Chaining exceptions in conjunction with the servlet

error mechanism shown in Code Example 5.16 may provide a generalized means

of displaying service exceptions.