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 Bharath Ganesh schrieb: > How about using one single wsdl:fault with the specific fault string and > detail set? > > This would mean the client always gets a fault in case of failure. At the > same time - > - Keeps the application simple - Not too many faults > - For a new error on the server, the wsdl still remains same, client remains > same.. > - I don't see any performance benefit at the client side if it has specific > faults. > > What do you think? > > On Mon, Feb 9, 2009 at 12:22 PM, Glen Mazza <[email protected]> wrote: > >> Hello, I have a design question. For a web service that handles standard >> database CRUD actions on a table, I was wondering about a good way to >> return >> error messages to the SOAP client based on standard database errors. >> >> For example, an "addWidget()" web service operation that adds a widget to >> the widgets table, multiple errors can occur: >> -- duplicate primary key >> -- unique key violation >> -- invalid value for a particular column >> -- foreign key not found >> >> One way to handle this would be to create a wsdl:fault for each type of >> error, which will get converted into a Java exception by wsdl2java. Then, >> have the web service provider throw the appropriate Java exception on error >> and have the SOAP client trap that error. >> >> But I think the client would still want a response even on a successful >> insert of a widget (instead of a one-way "ping" type SOAP client call when >> making the addWidget request.) A successful response would presumably just >> be a xsd:string with value of "OK". But since I would then have to return >> a >> response anyway, fail or no fail, perhaps it would be better to avoid >> wsdl:faults for database exceptions and just place the error in the >> response >> message, say with "FAIL" replacing "OK" and a detail element giving the >> problem. >> >> So I see two solutions: >> >> 1.) Standard SOAP response of "OK" if the addWidget() succeeds, specific >> wsdl:fault exceptions if it does not >> >> 2.) Standard SOAP response of "OK" or "FAIL", with a detail element giving >> the problem if the latter; no wsdl:faults are defined or used. >> >> Any idea which is better--or other ideas? >> >> Thanks, >> Glen >> >> -- >> View this message in context: >> http://www.nabble.com/Returning-database-SQL-errors-to-the-SOAP-client-tp21907792p21907792.html >> Sent from the cxf-user mailing list archive at Nabble.com. >> >> >
