You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Reinhard Sandtner <re...@gmail.com> on 2015/01/21 14:35:20 UTC
[DISCUSS] Converter - how to handle exceptions and default values
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
RE: [DISCUSS] Converter - how to handle exceptions and default
values
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
Hi all
- throwing an exception basically would work, returning null is the better (more efficient approach).
- Returning a non null value, will stop evaluation and the default value returned will be the final result,
subsequent converters that may be able to parse it correctly will never be called (see also my mail regarding the
commit from last night, returning Boolean.FALSE as default (hopefully not because FindBugs then is quite).
- If you want to have defaults these should be defined by low prioritized default config, not by the converters!
Cheers,
Anatole
-----Original Message-----
From: Reinhard Sandtner [mailto:reinhard.sandtner@gmail.com]
Sent: Mittwoch, 21. Januar 2015 14:35
To: dev@tamaya.incubator.apache.org
Subject: [DISCUSS] Converter - how to handle exceptions and default values
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
Re: [DISCUSS] Converter - how to handle exceptions and default values
Posted by Romain Manni-Bucau <rm...@gmail.com>.
PS: s/null/default value/? ie null for Object and "0" for primitives?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-21 18:08 GMT+01:00 Reinhard Sandtner <re...@gmail.com>:
> +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 <an...@credit-suisse.com>:
>>
>> 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:rmannibucau@gmail.com]
>> Sent: Mittwoch, 21. Januar 2015 16:12
>> To: dev@tamaya.incubator.apache.org
>> 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 <o....@swe-blog.net>:
>>> 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 o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> X http://xing.to/obf
>>>
>
Re: [DISCUSS] Converter - how to handle exceptions and default values
Posted by Reinhard Sandtner <re...@gmail.com>.
+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 <an...@credit-suisse.com>:
>
> 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:rmannibucau@gmail.com]
> Sent: Mittwoch, 21. Januar 2015 16:12
> To: dev@tamaya.incubator.apache.org
> 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 <o....@swe-blog.net>:
>> 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 o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
RE: [DISCUSS] Converter - how to handle exceptions and default
values
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
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:rmannibucau@gmail.com]
Sent: Mittwoch, 21. Januar 2015 16:12
To: dev@tamaya.incubator.apache.org
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 <o....@swe-blog.net>:
> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: [DISCUSS] Converter - how to handle exceptions and default values
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <o....@swe-blog.net>:
> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: [DISCUSS] Converter - how to handle exceptions and default values
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf