OK, but what do you do if there is *no* error and the database action occurred--return nothing, or return a string that just says "OK"?
I like the elegance of using a wsdl:fault for errors, but I was assuming I should still return something on success, and given that I going to be returning a response message on success, I could possibly use that same response message to list a failure. 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 > > 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. >>> >>> >> > > > -- View this message in context: http://www.nabble.com/Returning-database-SQL-errors-to-the-SOAP-client-tp21907792p21923178.html Sent from the cxf-user mailing list archive at Nabble.com.
