JDBC是Java里边一个很重要的组成部分，现代的很多软件应用，都和数据库相关，因此，JDBC起着日益重要的作用。即便一个Java开发工程 师不怎么直接使用JDBC，而是使用ORM等框架，但是这些框架也是给予JDBC包装而来的。因此，JDBC的不足，也给这些ORM还有数据库连接池组件 带来了很大的不便。
　　我们知道，Java的Statement(和PreparedStatement)，在execute查询和执行语句时，都需要检查 SQLException，这个SQLException实际上表示的涵义太宽泛了，这也就是我在题目中提到的“缺乏设计”，实际上，一个 Statement，执行的时候出错，有着多种可能，应该把这些错误分一下类来设计，这样表示的更清楚。
　　比如。在Statement去执行一个SQL时，很有可能是其所依赖的Connection被关闭了，这个时候，执行语句跑出的SQLException实际上是不合适的，应该是SQLConnectionException;
　　比如，要去一个不存在的表中select，执行时，跑出SQLException实际上是很对的;
　　但是我们看到，不管JDBC的版本怎么提升，从来也没有出现过SQLConnectionException这种东西，不管SQL执行时除了什么错，都是SQLExceptin。这非常像当初刚刚学Java时，写一个接口，通通声明为抛出Exception....
　　那么这个问题会影响到什么呢？如果每次使用都是直接创建连接，使用并且关闭还好，遇到异常就关闭就完事了，但是我们知道，目前很多开发使用的都是连接池，池化连接的close不是真正的关闭，而是将连接送回池中。
　　例如代码为：
Connection conn = null;  
try{  
  
    conn = pool.getConnection();  
    conn.....  
}catch(Exception ex){  
   ...  
}finally{  
  
  if(conn!=null)conn.close();  
}  
　　题在于，如果出现异常了(一般是SQLException)，应该怎么处理？按照逻辑，应该是如果是SQL查了一个不存在的表之类的，当然是连接回池，如果是连接坏了，当然是直接关闭。
　　但是现在我们能判断吗？因为只有SQLException，我们判断不出来。
　　根据SQLException的Message判断吗？不同数据库，Message是不同的。。。
　　还有可恨的，大多数数据库连接池，实际上是不向外提供“真正关闭一个连接”这个操作时，当然，这么做的考虑是为了屏蔽池化连接和直接创建的连接的区别，但是，这个接口封上之后，面对的这种问题应该怎么处理呢？
　　目前。大多数连接池也有一种办法解决，就是配置一个SQL，每次取出一个连接用的时候，都先执行一下，如果出错，表示连接坏了，连接池(连接池自身 当然能够真正关闭连接)真正关闭这个连接，给一个新的连接供外部请求者使用。但这是个拙劣的方法，因为一个SQL意味着和数据库的一个TCP交互，性能的 损耗是客观存在的，高并发、高效率的系统不应该用这种方法。
　　如果JDBC能够区分，那么将省去了很多麻烦，不管在连接池内部处理还是外部处理，至少都是符合逻辑的。在这里也建议使用一些开源数据库连接池组件 的朋友们，如果你要选择一种连接池，一定注意这种连接池这种情况下的处理，是怎样设计实现的，这一是表明了开发者考虑问题是否周全，而是关乎系统效率和稳 定性。
　　可能有的朋友会问，Java不会这么缺乏好的设计吗？我其实也不希望Java有这种缺陷，希望有一种好的机制来解决我的问题，但是很可惜没有看到。 之前曾经花了很大的力气研究Java的源码，曾经认为Java有很多地方值得学习，所以去研读。结果发现，有很多代码非常好，同时也发现很多代码很糟糕; 甚至不是实现代码的问题，而是设计时粗枝大叶。
　　一时、一天细心容易做到，但是在职业生涯中总保持细心、周全的考虑问题并不是件容易的事情，所以虽然觉得这里有问题，但是也不是嘲讽或者责难别人， 而是希望Java早一天认识到这些基础库的问题，对这些东西进行一些梳理和改进，做好基础语言，别盲目的追逐热点，把高楼大厦建立在沙滩上。
　　原文链接：http://windshome.iteye.com/blog/1921133

　JDBC是Java里边一个很重要的组成部分，现代的很多软件应用，都和数据库相关，因此，JDBC起着日益重要的作用。即便一个Java开发工程 师不怎么直接使用JDBC，而是使用ORM等框架，但是这些框架也是给予JDBC包装而来的。因此，JDBC的不足，也给这些ORM还有数据库连接池组件 带来了很大的不便。
　　我们知道，Java的Statement(和PreparedStatement)，在execute查询和执行语句时，都需要检查 SQLException，这个SQLException实际上表示的涵义太宽泛了，这也就是我在题目中提到的“缺乏设计”，实际上，一个 Statement，执行的时候出错，有着多种可能，应该把这些错误分一下类来设计，这样表示的更清楚。
　　比如。在Statement去执行一个SQL时，很有可能是其所依赖的Connection被关闭了，这个时候，执行语句跑出的SQLException实际上是不合适的，应该是SQLConnectionException;
　　比如，要去一个不存在的表中select，执行时，跑出SQLException实际上是很对的;
　　但是我们看到，不管JDBC的版本怎么提升，从来也没有出现过SQLConnectionException这种东西，不管SQL执行时除了什么错，都是SQLExceptin。这非常像当初刚刚学Java时，写一个接口，通通声明为抛出Exception....
　　那么这个问题会影响到什么呢？如果每次使用都是直接创建连接，使用并且关闭还好，遇到异常就关闭就完事了，但是我们知道，目前很多开发使用的都是连接池，池化连接的close不是真正的关闭，而是将连接送回池中。
　　例如代码为：
Connection conn = null;  
try{  
  
    conn = pool.getConnection();  
    conn.....  
}catch(Exception ex){  
   ...  
}finally{  
  
  if(conn!=null)conn.close();  
}  
　　题在于，如果出现异常了(一般是SQLException)，应该怎么处理？按照逻辑，应该是如果是SQL查了一个不存在的表之类的，当然是连接回池，如果是连接坏了，当然是直接关闭。
　　但是现在我们能判断吗？因为只有SQLException，我们判断不出来。
　　根据SQLException的Message判断吗？不同数据库，Message是不同的。。。
　　还有可恨的，大多数数据库连接池，实际上是不向外提供“真正关闭一个连接”这个操作时，当然，这么做的考虑是为了屏蔽池化连接和直接创建的连接的区别，但是，这个接口封上之后，面对的这种问题应该怎么处理呢？
　　目前。大多数连接池也有一种办法解决，就是配置一个SQL，每次取出一个连接用的时候，都先执行一下，如果出错，表示连接坏了，连接池(连接池自身 当然能够真正关闭连接)真正关闭这个连接，给一个新的连接供外部请求者使用。但这是个拙劣的方法，因为一个SQL意味着和数据库的一个TCP交互，性能的 损耗是客观存在的，高并发、高效率的系统不应该用这种方法。
　　如果JDBC能够区分，那么将省去了很多麻烦，不管在连接池内部处理还是外部处理，至少都是符合逻辑的。在这里也建议使用一些开源数据库连接池组件 的朋友们，如果你要选择一种连接池，一定注意这种连接池这种情况下的处理，是怎样设计实现的，这一是表明了开发者考虑问题是否周全，而是关乎系统效率和稳 定性。
　　可能有的朋友会问，Java不会这么缺乏好的设计吗？我其实也不希望Java有这种缺陷，希望有一种好的机制来解决我的问题，但是很可惜没有看到。 之前曾经花了很大的力气研究Java的源码，曾经认为Java有很多地方值得学习，所以去研读。结果发现，有很多代码非常好，同时也发现很多代码很糟糕; 甚至不是实现代码的问题，而是设计时粗枝大叶。
　　一时、一天细心容易做到，但是在职业生涯中总保持细心、周全的考虑问题并不是件容易的事情，所以虽然觉得这里有问题，但是也不是嘲讽或者责难别人， 而是希望Java早一天认识到这些基础库的问题，对这些东西进行一些梳理和改进，做好基础语言，别盲目的追逐热点，把高楼大厦建立在沙滩上。
　　原文链接：http://windshome.iteye.com/blog/1921133