David Johnston wrote:
>>>> It is impossible to fetch data when numeric value in database is NaN
>>> How do you expect what you read to be represented in Java?
>> java.lang.Double.NaN I guess.
> If the driver returns NULL is these situations it could still maintain internally
> whether the NULL is the result of a conversion of INF/-INF/NaN or whether the NULL was in the data
> itself. The driver could expose a "isNaN(), isPosInf(), and isNegInf() methods that the user could
> query upon seeing a NULL BigDecimal so that it knows the "meaning" of the NULL. Backward
> compatibility only requires that the BigDecimal is still returned, new features can be added.
I don't think that's a good idea.
Apart from the fact that a null pointer isn't a good representation
for an out-of-bounds value, that would change the behaviour and might
break applications that expect the current behaviour.
I think it is OK to throw an exception if a value cannot be represented,
but it should be a meaningful message.
Yours,
Laurenz Albe
