Chapter 3 Service Endpoint Design

83

  You cannot throw nonserializable exceptions to a client through the Web ser 

vice endpoint.

  When a service throws 

java

 or 

javax

 exceptions, the exception type and its 

context information are lost to the client that receives the thrown exception. 

For example, if your service throws a 

javax.ejb.FinderException

 exception 

to the client, the client may receive an exception named 

FinderException

, but 

its type information may not be available to the client. Furthermore, the type 

of the exception to the client may not be the same as the type of the thrown ex 

ception. (Depending on the tool used to generate the client side interfaces, the 

exception may even belong to some package other than 

javax.ejb

.)

As a result, you should avoid directly throwing 

java

 and 

javax

 exceptions to

clients. Instead, when your service encounters one of these types of exceptions,

wrap it within a meaningful service specific exception and throw this service 

specific exception back to the client. For example, suppose your service

encounters a 

javax.ejb.FinderException

 exception while processing a client

request. The service should catch the 

FinderException

 exception, and then, rather

than throwing this exception as is back to the client, the service should instead

throw a service specific exception that has more meaning for the client. See Code

Example 3.12.

...

try {

// findByPrimaryKey

// Do processing

// return results

} catch (javax.ejb.FinderException fe) {

throw new InvalidKeyException(

 Unable to find row with given primary key );

}

Code Example 3.12

Converting an Exception into a Service Specific Exception

E

Exception inheritances are lost when you throw a service specific exception.

You should avoid defining service specific exceptions that inherit or extend

other exceptions. For example, if 

CityNotFoundException

 in Code Example 3.10