Hi, Anurag, this sounds interesting, I generally like this kind of
approach over creating hardcoded specific SQLException classes in our
code. We should be able to solve this in a way that is less hardcoded
and more flexible, which is always good for long-term maintainability.
I don't quite get your approach of having the subclasses of
InternalDriver override the getFactory method; how does this work if the
method is static? I'm just having trouble picturing what the code looks
like to get the right exception.
Just trying to work it out myself, here's a pattern I came up with,
where everything's localized in InternalDriver and you don't need to
override in the Driver subclasses. It's a pretty standard factory
pattern. Would this work?
interface IExceptionFactory {
createSQLException(String messageId, ...);
}
class InternalDriver {
private static IExceptionFactory exceptionFactory_;
public static IExceptionFactory getExceptionFactory {
if ( factory == null )
factory = createExceptionFactory();
return factory;
}
// This isn't real code, I'm just trying to get the
// point across
private IExceptionFactory createExceptionFactory() {
switch ( jvmVersion ) {
case 1.3
return new JDBC2ExceptionFactory();
case 1.4
case 1.5
return new JDBC3ExceptionFactory();
case 1.6
return new JDBC4ExceptionFactory();
}
...
}
Then in code that wants to throw an exception you say
InternalDriver.getExceptionFactory().
createSQLException(SQLState.YADAYADA, ...);
Whaddya think???
David
Anurag Shekhar wrote:
Would it be acceptable for there to continue to be a static method in
Util that worked as it does today, always returning a
java.sql.SQLException? This method would have sanity checks to ensure
that the SQLState passed in did not start wiht any of the special values
that require specific sub-classes of SQLException. Then cases like
EmbedResultSetMetaData could use that method as the exeception it raises
does not have one of the special SQL states.
I have looked into the code base there are several places where
SQLException is instantiated directly but there out of these only two
has SQLStatus (ConnectionUtil.getCurrentLCC and
JNDIAuthenticationSchemeBase.getLoginSQLException)
Another way to solve this problem can be to set a separate exception
factory instance in InternalDriver class. If we have this in the
beginning of boot method of InternalDriver. This instance can be static
and once set need not be removed. Driver implementation can provide this
factory object by a method which can be overridden by the sub class of
InternalDriver. If the driver is booted after stopping boot method can
skip setting the factory instance as the Driver loaded will always be
latest version available for the jvm.
By doing this we don't have to worry about having the factory instance
being null and there will be uniform way of creating exception across
the code base.
anurag
anurag
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
