db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-796) jdbc 4.0 specific Blob and Clob method support
Date Thu, 16 Feb 2006 18:39:04 GMT
Daniel John Debrunner <djd@apache.org> writes:

> Knut Anders Hatlen wrote:
>
> d the createObject() method and rewritten
>> createJDBC40FactoryImpl() like this:
>> 
>>     private static ClientJDBCObjectFactory createJDBC40FactoryImpl() {
>>         final String factoryName =
>>             "org.apache.derby.jdbc.ClientJDBCObjectFactoryImpl40";
>>         try {
>>             return (ClientJDBCObjectFactory)
>>                 Class.forName(factoryName).newInstance();
>>         } catch (ClassNotFoundException cnfe) {
>>             return createJDBC40FactoryImpl();

I meant createDefaultFactoryImpl() here...

>>         } catch (Exception e) {
>>             RuntimeException rte = new RuntimeException(e.getMessage());
>>             if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14) {
>>                 rte.initCause(e);
>>             }
>>             throw rte;
>
> It's not typical to throw RuntimeExceptions as the above code does. I
> assume we think this will never happpen. Would a better approach be
> using the non-jdbc40 factory if the 4.0 can't be loaded?

I agree that it's a little awkward to throw a
RuntimeException. However, I think we should report it as an error
situation if

  1) we are running JVM >= 1.6, and
  2) the ClientJDBCObjectFactoryImpl40 class is found, and
  3) a ClientJDBCObjectFactoryImpl40 instance can't be created

which is the case when the RuntimeException is thrown. Anyway, I don't
think we should wrap the unchecked exceptions in a RuntimeException
(since the unchecked ones are RuntimeExceptions).

There are three checked exceptions that we can get at this
point. Therefore, we should have something like this:

    try {
        ....
    } catch (ClassNotFoundException cnfe) {
        // running mustang, but haven't compiled Derby with JDBC 4
        return createDefaultFactoryImpl();
    } catch (InstantiationException ie) {
        // couldn't create instance of factory because it's an
        // abstract class or interface
        ....
    } catch (IllegalAccessException iae) {
        // couldn't access constructor
        ....
    }
    // no general catch-all clause

I'm not sure what's the best way to handle InstantiationException and
IllegalAccessException. Maybe we could print a message to the console
saying "Unexpected error when loading Derby JDBC 4.0 driver. Please
check that your derbyclient.jar is not corrupted. Will fall back to
JDBC 3.0."

-- 
Knut Anders


Mime
View raw message