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 >
