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.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
