#63 TryVar2Int/Int64/LongWord/Bool return False for a variant that cannot be converted

[Thomas Mueller]

The variant conversion functions in u_dzVariantUtils are meant to tell two cases apart, as the comment above them has said since the initial import:

• Null or Empty: TryVar2Xxx returns False, Var2Xxx returns the Default
• a value that cannot be converted (e.g. the string 'abc' to Integer): EVariantConvertError

TryVar2Single, TryVar2Dbl, TryVar2Ext and TryVar2Str do that (see [#62]). TryVar2Int, TryVar2Int64, TryVar2LongWord and TryVar2Bool instead catch the EVariantError and return False, so the caller cannot tell a Null from bad data. Var2Int, Var2Int64 and Var2IntStr, TryFieldAsInteger in u_dzDatasetHelpers and the AssignVariant/FromVariant of the nullable integer types inherit that.

Fix: raise EVariantConvertError like the float and string functions do, and make the doc comments of the TryVar2Xxx and Var2Xxx functions say which case gives False / the Default and which one raises. Most of them currently say the Default is returned "if v can not be converted".

This changes the behaviour for callers that rely on getting False or the Default for data that cannot be converted. So all eight TryVar2Xxx functions also get an optional parameter _ErrorHandling: TErrorHandlingEnum = ehRaiseException, the same as TNullableDate.AssignVariant has: ehReturnFalse returns False instead of raising.

[Thomas Mueller]

Fixed in revision #2435