commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 21229] New: - ConnectionFactory throws SQLException but implementations don't
Date Tue, 01 Jul 2003 14:28:08 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21229>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21229

ConnectionFactory throws SQLException but implementations don't

           Summary: ConnectionFactory throws SQLException but
                    implementations don't
           Product: Commons
           Version: 1.0 Alpha
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Dbcp
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: bcampbell@servicemagic.com


Maybe I'm missing something here but this seems like a problem.
The createConnection() method on the ConnectionFactory interface throws 
SQLException.  However, all the implementations of the interface that I am
aware of do not throw SQLException but rather catch the SQLException and 
throw an unchecked DbcpException.  The DbcpException does wrap the SQLException
so the original exception information is not lost but the behavior is unexpected
and the abstraction breaks down a bit.  For example, the 
DriverManager.getConnection(String url)
javadoc says the method "attempts to establish a connection to the given 
database URL.
The DriverManager attempts to select an appropriate driver from the set of 
registered JDBC drivers"
and it throws SQLExcpetion "if a database access error occurs."  If you are 
using DBCP behind
the scenes, however, the DriverManager.getConnection method doesn't adhere to 
that contract
because it throws the unchecked DbcpException rather than the checked 
SQLException, if
there are problems accessing the database.  So if you want your code to deal 
with a 
down database in a specific way it must be aware that it is using DBCP and 
explicitly
catch DbcpException.  This is where the abstraction leaks a bit and DBCP 
becomes less
"plug able" and more tightly coupled with you client code.

I'm proposing the following change to the DriverManagerConnectionFactory (and 
similar
changes to the other implementations of ConnectionFactory).

Here's the code now:

public Connection createConnection() {
  try {
      if(null == _props) {
          if((_uname == null) || (_passwd == null)) {
              return DriverManager.getConnection(_connectUri);
          } else {
              return DriverManager.getConnection(_connectUri,_uname,_passwd);
          }
      } else {
          return DriverManager.getConnection(_connectUri,_props);
      }
  } catch(SQLException e) {
      throw new DbcpException(e);
  }
}

Here's my proposed change:

public Connection createConnection() throws SQLException {
   if(null == _props) {
       if((_uname == null) || (_passwd == null)) {
           return DriverManager.getConnection(_connectUri);
       } else {
           return DriverManager.getConnection(_connectUri,_uname,_passwd);
       }
   } else {
       return DriverManager.getConnection(_connectUri,_props);
   }
}


Not much to it really but I believe that makes the basic abstraction much 
stronger.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message