Daniel John Debrunner <[EMAIL PROTECTED]> 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
