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