better exception handling

Dmitri Dolguikh dmitri at redhat.com
Tue Apr 13 12:59:46 UTC 2010


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



More information about the candlepin mailing list