Hi Kris, hi Michael,
the status should ever be set as required by HTTP. IMO your approach
without setting the status breaks HTTP requirements. The status should
not say "OK", but it wasn't ok, because of an error.
I think you should return the status defined by the HTTP, and perhaps a
message in a format you like, e.g. text/plain or (why not) XML or JSON.
best regards
Stephan
Kris Bravo schrieb:
Hi Michael,
We're staying within the mediaType of the representation on our project.
For example, our app supports xml request/responses. When an error
occurs, we add a new <message> tag to the xml output containing the
information about the offending exception.
This way we can support transient errors, single errors is a
non-transactional batch, etc. Our .xsd files support <message> tags for
each Resource request/response pair we defined.
So if you consider our approach, setting the status code would only be
appropriate for mediatype HTML. Text, json, xml, etc would have a
message back with the error in it...
Kris Bravo
Michael Dunn wrote:
David,
Thanks for your response. I should have been more clear. I was wondering the
proper way from a service standpoint to return an error.
For example when inheriting from Resource in the server, - if the following code
generates an exception - is it better to return an error via the response or
throw an exception?
<code>
public void acceptRepresentation(Representation entity)
throws ResourceException {
try {
// Set the response's status and entity
} catch (Exception e) {
// OPTION 1
// which is the best way to return an error?????
// set it in the response as follows
response.setStatus(Status.CLIENT_ERROR_NOT_FOUND);
response.setEntity("Error", MediaType.TEXT_PLAIN)
// OR
// OPTION 2
throw new ResourceException(Status.CLIENT_ERROR_NOT_FOUND, "Error", e);
}
}
</code>
