+1 for return null if the converter can’t handle the value
we should write it in javadoc to make it clear

i've overlooked the exception handling in DefaultConfiguration, ups ;-)

lg
reini

> Am 21.01.2015 um 16:31 schrieb Tresch, Anatole 
> <[email protected]>:
> 
> Yep, it says, the converter is not able to parse the value. In that case, 
> within the chain of converters, it says go ahead the chain and try the next. 
> If at the end of the chain no converter was able to convert the value, a 
> ConfigException is thrown. That would the are, where we can also add 
> additional metadata, such as the possible supported formats.
> Regarding that returning Boolean.FALSE in case BooeanConverter is unable to 
> read it is not a valid implementation.
> 
> 
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:[email protected]] 
> Sent: Mittwoch, 21. Januar 2015 16:12
> To: [email protected]
> Subject: Re: [DISCUSS] Converter - how to handle exceptions and default values
> 
> I'd like to keep null since that's a valid value in enough cases to be
> handled IMO
> 
> 
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
> 
> 
> 2015-01-21 16:03 GMT+01:00 Oliver B. Fischer <[email protected]>:
>> Hi,
>> 
>> do we chain the converters already? If not it should either throw a
>> ConfigException or return a default value.
>> 
>> null is not an option IMHO
>> 
>> Oliver
>> 
>> Am 21.01.15 um 14:35 schrieb Reinhard Sandtner:
>> 
>>> Hi folks,
>>> 
>>> i’ve taken a look to our 'default‘ converters and the behavior of
>>> conversion errors and default values is not the same.
>>> 
>>> javadoc of the interface
>>> /**
>>>  * Convert the given configuration keys from it's String representation
>>> into the required target type.
>>>  *
>>>  * @param value the configuration value
>>>  * @return the converted value
>>>  */
>>> our BooleanConverter returns Boolean.FALSE as default value.
>>> our IntegerConverter calls Integer.decode() and throws a
>>> NumberFormatException if the string can’t be parsed.
>>> 
>>> imo if the converter can’t handle the input, the converter should return
>>> null.
>>> 
>>> My understanding is, that i can have n converters for a type and they try
>>> to convert the value in a chain ordered by @Priority until one of them
>>> returns a converted value (not null).
>>> 
>>> if no converter can handle the value, we should throw a Conversion- or
>>> ConfigException
>>> 
>>> WDYT?
>>> 
>>> lg
>>> reini
>> 
>> 
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E [email protected]
>> S oliver.b.fischer
>> J [email protected]
>> X http://xing.to/obf
>> 

Reply via email to