In a discussion with Prad, Adrian asked how we should handle exceptions in candlepin. Right now we seem to throw BadRequestException[1] whenever we have a problem.
The idea is we want to send back a 400 (or other proper HTTP code), then the client can read the response. In the response we want a JSON string that they can read what really happened.
Unfortunately, our current implementation yields a plain text string (not json) even if I change the code to be .type("application/json"). But if I pass a jaxb object to the Exception class it gets serialized properly.
So we'll create a ExceptionMessage object that can be jaxbified, that would contain the following attributes: name i.e. "invalid_argument" message i.e. text string as to what happened display message i.e. text string that can be displayed to the user
Then BadRequestException (and other wrapped exceptions) will contain an ExceptionMessage object inside.
A few things need to happen in this as well:
* need to figure out proper HTTP error codes and WHEN to send them * create ExceptionMessage class * create the wrapper exception classes
[1] BadRequestException is a wrapper around jax-rs WebApplicationException where we set the Response status to be BAD_REQUEST (400).
On 03/23/2010 01:54 PM, Jesus M. Rodriguez wrote:
In a discussion with Prad, Adrian asked how we should handle exceptions in candlepin. Right now we seem to throw BadRequestException[1] whenever we have a problem.
The idea is we want to send back a 400 (or other proper HTTP code), then the client can read the response. In the response we want a JSON string that they can read what really happened.
would it be based on the media type? Today, it is xml by default.. json is specified.
Unfortunately, our current implementation yields a plain text string (not json) even if I change the code to be .type("application/json"). But if I pass a jaxb object to the Exception class it gets serialized properly.
See above.
So we'll create a ExceptionMessage object that can be jaxbified, that would contain the following attributes: name i.e. "invalid_argument" message i.e. text string as to what happened display message i.e. text string that can be displayed to the user
localized??
Then BadRequestException (and other wrapped exceptions) will contain an ExceptionMessage object inside.
A few things need to happen in this as well:
- need to figure out proper HTTP error codes and WHEN to send them
- create ExceptionMessage class
- create the wrapper exception classes
When? Part of next sprint?
-- bk
On Tue, Mar 23, 2010 at 2:19 PM, Bryan Kearney bkearney@redhat.com wrote:
On 03/23/2010 01:54 PM, Jesus M. Rodriguez wrote:
In a discussion with Prad, Adrian asked how we should handle exceptions in candlepin. Right now we seem to throw BadRequestException[1] whenever we have a problem.
The idea is we want to send back a 400 (or other proper HTTP code), then the client can read the response. In the response we want a JSON string that they can read what really happened.
would it be based on the media type? Today, it is xml by default.. json is specified.
Right now we seem to hardcode text/plain, I'd like it to be based on the normal Accept header and let the framework do it automagically.
Unfortunately, our current implementation yields a plain text string (not json) even if I change the code to be .type("application/json"). But if I pass a jaxb object to the Exception class it gets serialized properly.
See above.
So we'll create a ExceptionMessage object that can be jaxbified, that would contain the following attributes: name i.e. "invalid_argument" message i.e. text string as to what happened display message i.e. text string that can be displayed to the user
localized??
I think that's the intent not sure if we need that or not. But would be nice if the client could ask for the potentially localized text in the future. But I'm not married to it, I'd be fine with name and message :)
Then BadRequestException (and other wrapped exceptions) will contain an ExceptionMessage object inside.
A few things need to happen in this as well:
- need to figure out proper HTTP error codes and WHEN to send them
- create ExceptionMessage class
- create the wrapper exception classes
When? Part of next sprint?
Hell I would've done it this week, probably should be there for the client bits before next sprint.
jesus
candlepin@lists.fedorahosted.org