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
