项目错误列表之一

    调试是编码过程中最消耗时间的一个过程，尤其是当你发现问题的原因后，这些error 往往令人哭笑不得。我大致将它们整理出来，但愿同样出于困境的朋友，能在其中得到一些启发。

问题之一：

问题背景描述：一个DataTable绑定DataGrid，目标是要实现点击按钮，删除当前行。最后面有一个删除按钮列，在delete事件中，我写下了如此逻辑：

foreach (DataRow row  in  table.Rows) {
     if (row[“productName”].Equals(proName)) {
    table.Rows.Remove(row);
    }
}

table为DataTable， proName为string，保存的DataGrid当前行的一个关键字段。循环判断每行row中是否有与它一致的字段，有则删除。而发生的错误字里间意思很明白，这是一个设定，集合被修改后，无法进行遍历的操作。而在后来的调试过程中，用一句话就代替了这个循环：table.RemoveAt(e.Item.DataSetIndex); 你可能无法获取当前行在DataTable中的行数，但你可以获得它在DataGrid中的行数，而DataTable与DataGrid绑定了，数据行上一一对应。

这个错误对熟悉.net的人来说，或许根本就没什么，太低级。但却让我明白：如果你已经适应了java的事事亲力亲为，而来行.net事时，得放松一下，.net有一些很傻瓜的方法将操作包装了起来。（记得以前的AWT写窗口关闭事件时，还要添加窗口适配器，然后在方法体中添加System.exit(0);，而后来SWING中，一句话就搞定了你一个繁杂的内隐类；再比如，如果不用到webwork，很多页面上的数据验证，你需要写一大堆的js和后台校验类。而前者仅仅需要一个标签。）

万事都在发展，近些天，用Eclipse居然发现装一些插件后，居然可以像.net一样设置断点来调试，一样有丰富的联想（类名、方法的联想不稀奇，但那个是文件路径的联想），我便无言，java在成长，编码过程将被工厂化、模型化，难度和深度将会由专家来实现，团队更多的将精力集中到与客户的沟通、对业务的理解上。那么，像我们这样的程序员到什么地步呢？

也许哪一天，普通程序员的生产和制造将应用Factory Model，大量而源源不断......