You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Dyre Tjeldvoll <Dy...@oracle.com> on 2014/07/08 14:14:31 UTC
Question about DataType.invalidFormat()
Hi,
This method returns an exception which is thrown by
SQLInteger.setValue(String theValue) if the String passed in cannot be
converted to an integer:
try {
value = Integer.parseInt(theValue.trim());
} catch (NumberFormatException nfe) {
throw invalidFormat();
}
But when this situation occurs, it would have been really nice for the
caller to be able to inspect the actual NumberFormatException which was
thrown as that may say something about what is wrong with the String
being passed in. So I would like to have an alternate
invalidFormat(Exception cause) (assuming there are situations where
there is no exception to use as cause) that captures the
NumberFormatException as the thrown exception's cause... Would there be
any backward compatibility issues with such a change?
--
Regards,
Dyre
Re: Question about DataType.invalidFormat()
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Hi Dyre,
On 08. juli 2014 14:14, Dyre Tjeldvoll wrote:
> Hi,
>
> This method returns an exception which is thrown by
> SQLInteger.setValue(String theValue) if the String passed in cannot be
> converted to an integer:
>
> try {
> value = Integer.parseInt(theValue.trim());
> } catch (NumberFormatException nfe) {
> throw invalidFormat();
> }
>
> But when this situation occurs, it would have been really nice for the
> caller to be able to inspect the actual NumberFormatException which
> was thrown as that may say something about what is wrong with the
> String being passed in. So I would like to have an alternate
> invalidFormat(Exception cause) (assuming there are situations where
> there is no exception to use as cause) that captures the
> NumberFormatException as the thrown exception's cause... Would there
> be any backward compatibility issues with such a change?
>
I think would be an acceptable improvement from a compatibility
perspective. More information is better.
Dag