db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Date Tue, 08 Nov 2005 23:10:52 GMT
Hi, Dan, I get it now.  Yes, I think this is feasible, and I'll work on 
that.  The network client code could do something like

throw ExceptionUtil.newSQLException(SQLState.ERRCODE, arg1, arg2);

Meanwhile, your inspection of and comments on the rest of the patch 
would be much appreciated!

David

Daniel John Debrunner wrote:
> David Van Couvering (JIRA) wrote:
> 
> 
>>     [ http://issues.apache.org/jira/browse/DERBY-289?page=all ]
>>
>>David Van Couvering updated DERBY-289:
>>--------------------------------------
>>
>>    Attachment: DERBY-289.diff
>>
>>Hi, all.  Here is the proposed patch that provides the framework for code sharing.
 I was thinking folks could look at it and discuss, and then once issues have (hopefully)
been worked out, we can have a vote.
>>
> 
> 
>>- Created a new SQLException class for the client, SQLException2, which makes use
of the common framework. 
>>I did this rather than modify the existing class because I wanted a
> 
> well-structured way to  migrate exception
> 
>>code over incrementally.
> 
> 
> Is there a way to start out the common code that does not require
> sub-classing SQLException? Once JDBC 4.0 is supported it seems that
> subclassing SQLException for Derby is no longer viable (or maybe
> desirable) as JDBC 4.0 provides a number of SQLException classes. Thus,
> looking forward, I don't think we want to have Derby specific
> sub-classes for every JDBC SQLException class or sub-class.
> 
> This is what I meant in a post a while ago about using SQLException
> directly, rather than sub-classing it. I realise I never replied on
> that. Sorry.
> 
> Dan.
> 
> 

Mime
View raw message