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.
-d