On 04/13/2010 08:59 AM, Dmitri Dolguikh wrote:
On 10-04-13 9:13 AM, Bryan Kearney wrote:
On 04/12/2010 05:28 PM, Jesus Rodriguez wrote:
On Mon, Apr 12, 2010 at 03:46:13PM -0400, Bryan Kearney wrote:
On 04/12/2010 03:41 PM, Dmitri Dolguikh wrote:
On 10-04-12 3:56 PM, Bryan Kearney wrote:
On 04/12/2010 01:41 PM, Dmitri Dolguikh wrote:
> I committed the first cut of parseable exceptions. The 'interesting' > parts: > > CandlepinExceptionMapper.java - the bit that maps exceptions thrown by > Resources to http responses > CandlepinException.java - base class for exceptions > BadRequestException.java - I modified just one exception to be handled > by the ExceptionMapper, as a trial/demo > Looks good all and all. One comments.. is the label meant to be the ID? If so, should we have a list of valid ids?
I like the current implementation with the mapper handling the proper serialization and the specific BadRequestException.
I'm not sure. I thought it was short message/long message. More or less for disambiguation of http return codes.
Well.. before we go too far. Lets figure this out (as well as i18n). If we are going to go throgh the code, lets do it once.
+1 so what would we like to have with respect to the messages? We could stick with short& long messages, and just use i18n keys for it.
I had been assuming something akin to the following:
new Exception("not_found", "The Consumer with ID %s was not found", consumer.id)
where the first string is a type or id, the second string is what will eventually be localized, and then a collection of objects which can be the messages. We could get fancy and do a hash for the last parameter and do key->value substitution instead of positional.
-- bk
I think that makes sense/works. I'm going to code it up and we'll see what everybody (and by that i mean Jesus and Bryan) thinks.
What is the latest and greatest i18n framework? Perhaps there is a better way. Guice is frickn voodoo.. so there may be a magic way for guice to do it.
-- bk