I did some googling and I found an email that was send by Michael J. Hudson that says that the Call objects getFullTargetObjectURI() gets wiped out when there is a Soap Fault. His workaround solution is to save the full target object uri before the call and reset it after in the case where there is a fault.
Here is the email in full http://marc.theaimsgroup.com/?l=soap-user&m=99748693307691&w=2 In his email, Michael asks when this bug is going to be fixed. Obviously, it has not been fixed ;) Does anyone know if this is indeed a bug or desired behavior? > -----Original Message----- > From: George Voronoff > Sent: Friday, January 11, 2002 4:11 PM > To: [EMAIL PROTECTED] > Subject: Exception Handling/Error Reporting > > > I'm a soap Newbie and I have some questions about soap and > error reporting. > > lets say I have a server side method: > > public Address getAddressFromName(String name) throws > IllegalArgumentException > { > if (name == null) > { > throw new IllegalArgumentException("The name argument > must not be " + "null."); > } > > return (Address)name2AddressTable.get(name); > } > > This method was copied directly from the address book example. > If name is null the server throws an IllegalArgumenException, > and and the response Fault looks like: > > Generated fault: > Fault Code = SOAP-ENV:Server > Fault String = Exception from service object: The name > argument must not be null. > > NOW, If I call the invoke() again (on the same Call ojbect) I > get a different fault. > > Generated fault: > Fault Code = SOAP-ENV:Server.BadTargetObjectURI > Fault String = Unable to determine object id from call: is > the method element namespaced? > > It seems to me that throwing the first exception from a > server side method caused "something bad" to > happen to the Call object. As such, do I need to avoid > throwing server side exceptions at all costs if > I want to reuse the same Call object? > > Is it good practice to avoid throwing server side exceptions > in the first place? > > Finally, can someone point to to any documentation that > discusses implementiing reporting of > server side errors. > > > George Voronoff > > Senior Software Engineer (Net Hack) > > Grassroots Enterprise, Inc > > > > > > >
