(Thanks Benson and Bharath for your suggestions.) Jaro, just to clarify, when you say a "single soap fault type" do you mean you throw a SOAPFaultException (which is not defined within the WSDL) or is it a single wsdl:fault defined in the WSDL? I guess it really doesn't matter, but just want to get a better idea of your design.
Also, in your latest post in this thread, you say the method returns an empty complex type--just to confirm, the SOAP client does *not* need to bother to inspect that empty complex type on return, the fact that the method returned with no SOAP exception thrown means everything's good, correct? Also, that single empty complex type defined in the WSDL can be used for countless different database CRUD-type web service operations, providing you throw exceptions on an error, correct? I.e., InsertWidget, InsertThingy, UpdateWidget, DeleteThingy, etc. can all use that same return type providing you don't need to return any real information for a successful web service call. Thanks, Glen Jaroslav Libak-2 wrote: > > Hello > > I use a single soap fault type, with integer code and string message. > String > message is only meant for debugging, and usually contains exception > message (or > class name), including messages of nested exceptions. Integer codes > roughly > correspond to HTTP error codecs, and determine error handling of client. > > You should avoid having too many fault types, and adding new fault types > to > existing web service methods. > > Jaro > -- View this message in context: http://www.nabble.com/Returning-database-SQL-errors-to-the-SOAP-client-tp21907792p21924608.html Sent from the cxf-user mailing list archive at Nabble.com.
