Re: Bug : FAST_NUMBER_FAILED when getting NaN on BigDecimal

> -----Original Message-----
> From: Albe Laurenz [mailto:laurenz.albe@wien.gv.at]
> Sent: Wednesday, September 12, 2012 10:48 AM
> To: David Johnston *EXTERN*; Florent Guillaume; Kevin Grittner
> Cc: DocSea - Patrice Delorme; pgsql-jdbc@postgresql.org
> Subject: RE: [JDBC] Bug : FAST_NUMBER_FAILED when getting NaN on
> BigDecimal
> 
> 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.
> 

OK.  So the API would be more along the lines of: "if you are concerned with NaN/Infinity values you can poll the result first to see if the returned value is valid or not.  If the returned value is invalid and the user tries to read the value they get their exception.  If the user sees that the value is invalid (from the polling) then they should forego reading the value and instead interpret whatever invalid value is indicated.  An actual NULL would be a valid value."

I am unsure exactly WHEN the exception in this case is thrown but if too early then sub-classing BigDecimal is not possible since the exception would preclude the object ever being created (for backwards compatibility).

Personally, I believe there needs to be some way to access this aspect of the PostgreSQL numeric type but it is not something that, aside from a desire for completeness, currently affects me.  Even a more fine-grained exception hierarchy (NaNException, PositiveInfinityException, NegativeInfinityException) that the user could catch on could be helpful (instead of having to perform string manipulation of the error message).  In any cases a non-standard class would be necessary so whether the driver provides ones or it simply provide information and requires the user to code whatever Class is appropriate is an explicit decision to make.

David J.