better exception handling

Dmitri Dolguikh dmitri at redhat.com
Fri Apr 9 13:32:52 UTC 2010


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 at 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




More information about the candlepin mailing list