On 04/07/2010 05:34 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We have a task to get better exception handling from the API and the
client. We'd like to have better error messages and possibly error
codes, as well as json serializable.
Today we throw the following exceptions:
ForbiddenException - thrown from ConsumerResource
NotFoundException - thrown from a few Resources
BadRequestException - thrown from almost all Resources
WebApplicationException (parent to the above) - called directly
The above exceptions extend WebApplicationException and for the
return type to be "text/plain", which means you can't parse
it as JSON on the client side. This is odd since all other responses
are in JSON, it would be nice to be consistent. Sadly it isn't
enough to leave off the type call as it will default to text/plain.
In order to get it serializable the thought is to create a class
to be used as the payload for the Exceptions, say something like
ExceptionMessage. This class will be annotated with JAXB objects
and can be used to return as JSON or XML based on the Accept header,
just like the other API calls do.
The thought is to have it contain the following:
* error code - int
* label - string
* display message - string (i18n probably)
We may not need the error code since the HTTP codes might be enough,
then we'd just need to have decent message strings.
If we do have an error code internally, we would need a way to map that
to http error code. I would be all for label/string and pick the correct
status code you want. If the labels are unique, it may be the same as
the error code.
HTTP status codes -
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
ResponseStatus javadoc -
http://bit.ly/aMhkkM
Now on the exception side, we can continue to create wrapper exceptions
like BadRequestException OR we could use standard exceptions and use
the RESTeasy ExceptionMapper to map a standard exception to a proper
Response code. I personally like the wrapper exceptions since it makes
it more explicit, then use the ExceptionMapper for a final catchall
like NullPointerException, and other gross things that we might want
to offer a nicer error message to easy the pain :)
+1
All in all the main key is to identify better error messages that the
client can use and make it consistent for Resource developers.
Just thinking ahead, how would validation error fit into this? Would it
be a 406, with label of "validation_failed" and the message would be the
items whic hfailed? Or.. would we have a one-off validation_Exception?
-- bk