I'm not a fan of WSDL faults except for web-service specific problems. Here's why. Often, I find that the code that I want to call via a web service today I want to call directly tomorrow. Given that faults rarely map quite precisely to exceptions, I'd build errors like this into the protocol and map them out to exception further out.
On Mon, Feb 9, 2009 at 5:10 PM, Glen Mazza <[email protected]> wrote: > > 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. > >
