rootvector2 commented on PR #411: URL: https://github.com/apache/commons-beanutils/pull/411#issuecomment-4896007450
The split is decided at construction time, not per error. Every builder sets `useDefault || defaultValue != null`, and `BaseLocaleConverter.convert` catches anything `parse` throws: with `useDefault` it returns the default, otherwise it rethrows as `ConversionException`. So it's all-or-nothing per instance, and I agree it's narrow: the default only kicks in on null input or a `parse` failure. That's also why this patch doesn't introduce a new policy. It reclassifies a fractional result as a parse failure and lets the existing dispatch decide. A converter built with a default keeps returning the default (the `(B)` assertions and `testNonIntegerRejected` pin that), and only converters built without one start throwing. Call sites relying on `"5.5"` mapping to `5` were already getting the default for `"abc"` or out-of-range input, so fractions just join the errors that were already handled that way. On 1.X I agree least surprise wins. #407 landed the out-of-range rejection there, but truncating fractions is much older behavior, so I'd hold off on a 1.X port unless you want one. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
