better exception handling

Bryan Kearney bkearney at redhat.com
Thu Apr 8 13:31:10 UTC 2010


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



More information about the candlepin mailing list