users@jax-rpc.java.net

Re: xrpcc questions

From: Sasi Kala <sasikala_jmk_at_YAHOO.COM>
Date: Tue, 06 Aug 2002 07:09:15 -0600

Hi Doug Kohlert,

You have answered in your previous mail that we could have only one getter method in user defined service specific exception that returns a particular type. Why this restriction in the present release? and will it be resolved in the next release?

Regards,
Sasikala.

--------------------------------
Your Answer
-----------------------------------
The FCS version of jaxrpc released in the jwsdp 1.0 release will allow
you to throw service specific exception from your server's
implementation class and catch them on your jaxrpc client if the
exceptions match the following format.

The exception class must have a constructor that has one parameter for
each getter method defined on the exception, the parameter types must
match the types of the getter methods. You can only have one getter
method that returns a particular type.

for example

public class MyException extends Exception {

   public MyException(String name, int age)...

   public int getAge()...

   public String getName()...
}

will work. however;

public class MyException extends Exception {

   public MyException(String name, String address, int age)...

   public int getAge()...

   public String getName()...
   public String getAddress()..
}

will not work because the getName and getAddress method both return type
String.

This exception can be caught on the client as a SOAPFaultException.


---------------------------------
for the question
---------------------------------

> 2. On a related topic, when I make the call to the service method from my Java client
> through the generated stub, any exception that the service method throws is getting
> wrapped in a SOAPFaultException when it gets to the client. Since the XML
> representation of the exception class gets placed in the detail element of the fault
> element, couldn't the jaxrpc stub create the service-thrown exception from the xml on
> the client side and have that be the exception that is thrown from the soap call?
> Therefore, instead of having to catch SOAPFaultException, I could have a catch for the
> actual exception the service throws?

------------------------------------