On 10-04-08 10:58 AM, Adam Young wrote:
On 04/08/2010 09:31 AM, Bryan Kearney wrote:
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 _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
In addition to the error codes, can't we provide custom error pages, that could potentially be straight JSON, with the error info in a standard format?
i think content-type should take care of that? We could serialize exception information differently, depending on whether the client requests json or plan text (or xml).
-d