better exception handling

Bryan Kearney bkearney at redhat.com
Tue Apr 13 17:10:17 UTC 2010


Another thing to noodle.. we will want the user service to be able to 
throw exceptions with interesting messages at login time.  Does the 
current approach allow the filters to throw exceptions.

-- bk

On 04/09/2010 09:32 AM, Dmitri Dolguikh wrote:
> 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
>
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin




More information about the candlepin mailing list