Java 结果集“；“未找到列”；与c3p0

我对数据库进行了查询，结果是通过

java.sql.ResultSet

获得的，因为此查询是动态的，返回的列数可能是5或7，在过去，使用相同的代码生成了一个“column not found exception”，并包含在以下捕获中：

try{
    sTemp = this.rsResults.getString("col3");
   }catch(Exception e){}

但是现在使用相同的try-and-catch（唯一的区别是现在我使用的是

combopooldatasource

及其连接），我得到了两个不属于catch的异常

我该如何改进这一点，是否有更好的方法来检查列是否存在？ c3p0是否必须基于

（SQLState:S0022）列未找到错误强制测试连接

Error n1 - in the com.mchange.v2.c3p0.impl.NewProxyResultSet.getString qlUtils.toSQLException() - Attempted to convert SQLException to SQLException. Leaving it alone. [SQLState: S0022; errorCode: 0]
java.sql.SQLException: Column 'col3' not found.

Error n2 -  DefaultConnectionTester.statusOnException() - Testing a Connection in response to an Exception:
java.sql.SQLException: Column 'col3' not found.

ps：使用的驱动程序与org.gjt.mm.mysql.driver相同

检查

结果元数据

ResultSet rs = stmt.executeQuery("SELECT * FROM your_table");

ResultSetMetaData rsmd = rs.getMetaData();
int numberOfColumns = rsmd.getColumnCount();

// test the number of columns returned
if (numberOfColumns == 5) {
    //
} else {
    // numberOfColumns = 7
}

// or, test the column names
if ("col3".equals(rsmd.getColumnName(3)) {
    // col3 exists
}

编辑：
如果您不想对源代码进行修改，只希望当前的方法也能使用

c3p0

；只需捕获可丢弃的。（但这确实让我不寒而栗：）

---

检查

ResultSetMetaData

ResultSet rs = stmt.executeQuery("SELECT * FROM your_table");

ResultSetMetaData rsmd = rs.getMetaData();
int numberOfColumns = rsmd.getColumnCount();

// test the number of columns returned
if (numberOfColumns == 5) {
    //
} else {
    // numberOfColumns = 7
}

// or, test the column names
if ("col3".equals(rsmd.getColumnName(3)) {
    // col3 exists
}

编辑：
如果您不想对源代码进行修改，只希望当前的方法也能使用

c3p0

；只需捕获可丢弃的。（但这确实让我不寒而栗：）

---

c3p0对任何类型的异常进行内部测试，但此测试中的异常不会引发或对客户端代码可见。您之所以看到它，是因为您正在调试级别记录c3p0输出。c3p0材料应记录在信息中，以便正常使用。如果您在调试级别登录，您将看到各种警报消息和堆栈跟踪。

c3p0在内部测试任何类型的异常的连接，但此测试中的异常不会引发或对客户端代码可见。您之所以看到它，是因为您正在调试级别记录c3p0输出。c3p0材料应记录在信息中，以便正常使用。如果您在调试级别登录，您将看到各种警告消息和堆栈跟踪。

我做了以下（粗略）测试，只是为了说明在我的特定情况下，引发异常与检查记录集中是否存在列的成本

要检查的列数为169

代码1

try
{
 sTemp = this.rsResults.getString("col3");
}catch(Exception e){}
try
{
 sTemp = this.rsResults.getString("col4");
}catch(Exception e){}

...

try
{
 sTemp = this.rsResults.getString("col169");
}catch(Exception e){}

代码2，函数为hasColumn[问题]：

结果无c3p0

           code 1   code 2
query nº1   75ms     36ms
query nº2   40ms     43ms
query nº3   227ms    46ms
query nº4   262ms    18ms

c3p0对数水平为INFO的结果

           code 1   code 2
query nº1   519ms     45ms
query nº2   358ms     28ms
query nº3   2348ms    9ms
query nº4   3243ms    12ms

作为结论，在这两种情况下，仅仅为了检查列是否存在而引发异常的成本（除了不好的做法）都很高，尤其是在使用c3p0时。我做了以下（粗略）测试，只是为了说明在我的特定情况下，引发异常与检查记录集中是否存在列的成本

要检查的列数为169

代码1

try
{
 sTemp = this.rsResults.getString("col3");
}catch(Exception e){}
try
{
 sTemp = this.rsResults.getString("col4");
}catch(Exception e){}

...

try
{
 sTemp = this.rsResults.getString("col169");
}catch(Exception e){}

代码2，函数为hasColumn[问题]：

结果无c3p0

           code 1   code 2
query nº1   75ms     36ms
query nº2   40ms     43ms
query nº3   227ms    46ms
query nº4   262ms    18ms

c3p0对数水平为INFO的结果

           code 1   code 2
query nº1   519ms     45ms
query nº2   358ms     28ms
query nº3   2348ms    9ms
query nº4   3243ms    12ms

---

总之，在这两种情况下，仅为检查列是否存在而引发异常的成本（除了不好的做法）都很高，尤其是在使用c3p0的情况下。

感谢您的回复，结果元数据如果可以检查col3是否存在，但col3会改变其在选择状态中的位置。ResultSet的getString方法非常完美，因为如果列不存在，则返回如中所述的异常，我的问题是在使用c3p0时出现此异常。我既不喜欢Throwable，因为我不想记录任何东西，也不想处理除了未找到列之外可能出现的任何错误和异常。我将对源代码进行更改，这是最好的方法。感谢您的响应，如果检查col3是否存在，但col3会更改其在选择状态中的位置，则返回ResultSetMetaData。ResultSet的getString方法非常完美，因为如果列不存在，则返回如中所述的异常，我的问题是在使用c3p0时出现此异常。我既不喜欢Throwable，因为我不想记录任何东西，也不想处理除了未找到列之外可能出现的任何错误和异常。我将更改源代码，这是最好的方法。是的，这是真的，但是如果我将日志设置为INFO，连接测试仍然会发生吗？如果是，那么提升测试和异常堆栈的成本仍然很高，这就是我想要避免的，测试仍然会发生。c3p0假定异常指示异常情况，并始终在异常后进行测试，以确定连接是否适合在池中重复使用，或是否应在关闭时标记为销毁。如果您设置preferredTestQuery或AutomatictTestTable属性，连接测试不需要非常昂贵。不过，默认测试通常比较慢。好的，谢谢Steve。我认为异常（col not found）的代价是最困扰我的，我正在对原始代码（try&catch with SQLException column not found）和修改后的代码（检查ResultSet.getString（）之前是否存在列）进行一些测试，无论是否有c3p0，完成后我都会在这里发布结果。是的，但是如果我将日志设置为INFO，连接测试仍然会发生吗？如果是，那么提升测试和异常堆栈的成本仍然很高，这就是我想要避免的，测试仍然会发生。c3p0假定异常指示异常情况，并始终在异常后进行测试，以确定连接是否适合在池中重复使用，或是否应在关闭时标记为销毁。如果您设置preferredTestQuery或AutomatictTestTable属性，连接测试不需要非常昂贵。不过，默认测试通常比较慢。好的，谢谢Steve。我认为异常（col not found）的代价是最困扰我的，我正在用原始代码进行一些测试（try&catch-wit）