先说点题外话。请注意，我已把用来遍历表的代码抽出来放到了抽象类 Walker 中，以使新的子类可以很容易地遍历表中的行。虽然试图预测程序被扩展的各种方式并为其编写代码通常是浪费时间，但还是让我们假设在此例中绝对地，毫无疑问地，无论如何对代码只做这一类的扩展。（事实上，我可以保证在本文结束前，只会有这样一种扩展）。

　　症状

　　现在，请注意数据库连接被传递到了 TableWalker 的构造函数中。一旦完成对表的遍历，它就将关闭连接。

　　所以，在这个例子中，我们采用第二种策略来清除连接。我们已经尝试过沿着每一条执行路径分别关闭连接。

　　让我们假设在我们的系统环境中，在一次遍历数据后关闭连接是有意义的（例如，也许这段代码会被从命令提示符中调用）。即使在那种情况下，我们也不能捕捉到每一条可能的执行路径 — 如果抛出了 SQLException ，程序可能会在关闭连接前异常终止。

　　因为 SQLException 在成熟代码中很少见，所以这个错误可能在很长一段时间内都不会（可能在原开发人员已经转行后也不会）表现出什么症状。自然地，这使得在症状 真的表现出来时，诊断起来就更加困难。

　　但是如果扩展了代码，就会有一些方式使症状的出现变得快得多。

　　例如，我们假设在原始代码写好后，发现存档的许多电话号码明显是过时的。于是管理人员决定把所有员工的电话号码都替换为 411。为完成这个更新，新写一个 TableWalker 如下：

　　清单 2. 更新过时数据的 walker 代码

class TableFixer extends TableWalker { public TableFixer(Connection _con, String _tableName) { super(_con, _tableName); } public void execute(ResultSet rs) throws SQLException { String s = rs.getString("FIRST_NAME"); String updateString = "UPDATE " + tableName + "SET PHONE_NUMBER = " + "411" + "WHERE FIRST_NAME LIKE '" + s + "'"; Statement stmt = con.createStatement(); stmt.executeUpdate(updateString); } }

　　因为 TableFixer 也继承 TableWalker ，所以在这个类的一个实例上调用 walk 将关闭与该数据库的连接，就象 TablePrinter 一样。如果一个程序试图用同一个连接生成两个 walker 的实例，将发现第一个 walker 一完成遍历后连接就被关闭了。编程新手很容易犯这样的错误，特别是如果不变量 ― 就是说只能构造一个 walker ― 没有文档或未测试过的话。