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(a)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