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:[email protected]] Sent: Mittwoch, 21. Januar 2015 14:35 To: [email protected] 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
