Chris: I use faults for this. Faults are not exceptions, even though most frameworks can turn one into the other for you :)
However, to prevent fault overload, I normally set up two faults for most operations, one for the "you gave me some stupid data" and one for the "oh crap, hibernate blew up underneath me!" type errors. We use bpel for service orchestration, so the "hibernate exploded" errors we can normally just retry later, (maybe days later, when things have been fixed, but we can just rerun them) whereas the bad input type of data, just causes a fault, and someone gets notified. Our bpel engine let's us edit the input data and try again if we wish, or simply terminate the process. Cheers, Karl P > -----Original Message----- > From: Zarar Siddiqi [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 14, 2007 5:13 AM > To: [email protected] > Subject: Re: [xfire-user] To Throw a Fault Or Not To Throw a Fault? > > There's no rule that says faults should be used for system > level exceptions. It might be easier and neater for your > application to just throw faults, it really depends on how > much detail you want to provide back to the client. > > > > On 3/13/07, Christopher Moesel <[EMAIL PROTECTED]> wrote: > > > > > > > > > > This is not specifically related to XFire, but I value XFire users' > > and developers' opinions, so I hope you do not mind me asking here. > > > > > > > > I am working on the design of our exception and error > handling in web > > services. One thing I am dealing with is the decision as > to when to > > return faults versus when to return a status element > indicating an error. > > > > > > > > It seems to be a popular opinion that faults should be reserved for > > system exceptions (that is, unexpected errors) and status elements > > should be used for application exceptions (those errors that are > > expected to occur in regular business interactions). While I agree > > that this seems a good idea, I've run into one problem. > Here is an example: > > > > > > > > Suppose I have an operation called GetTodaysRedSoxScore. > The response > > XSD might look like this: > > > > > > > > <xsd:complexType name="GetTodaysRedSoxScoreResponseType"> > > > > <xsd:sequence> > > > > <xsd:element name="Status" type="tns:StatusType" /> > > > > <xsd:element name="Opponent" type="xsd:string" /> > > > > <xsd:element name="SoxScore" type="xsd:int" /> > > > > <xsd:element name="OpponentScore" type="xsd:int" /> > > > > </xsd:sequence> > > > > </xsd:complexType> > > > > > > > > Now suppose that someone invokes this operation on the Red > Sox's day off. > > Since this is really an application-level exception, many > would say we > > should return a status indicating "NO_GAME_SCHEDULED" or something > > like that (instead of using a fault). BUT… Opponent, SoxScore, and > > OpponentScore are all required elements… So I have about 4 choices: > > > > (1) Exclude these elements from my response (thus > returning XML that > > is not valid against my own schema) > > > > (2) Return default values for the required elements (empty > string for > > string, 0 or -1 for int, etc) > > > > (3) Change the XSD to make all elements nillable > > > > (4) Change the XSD to make all elements minOccurs="0" > > > > > > > > I don't really like any of these options, so I'm tempted to use a > > fault, even though it's not a system level exception. > > > > > > > > Is there a best practice that anyone is aware of? > > > > > > > > -Chris > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
