近期开始接触到在校学生、高校实习生和毕业生，在此说一下笔者对这些徘徊在职场门口的学生一些建议,希望能给这些初学者进入软件开发行业带来一些帮助,使得毕业生能更顺利的进入软件开发公司开始职场生涯，人生来一个完美的转弯。

-----------------------------------------------------------------------

     开发者应当遵守“尽早暴露错误”的开发原则，这是因为程序错误是客观存在的事实，应当正视它并有效的处理它，而不是简单粗暴的和谐掉。而且在开发中应当尽早暴露出程序的错误，这有助于发现错误的本质，帮助改善程序质量；若一味的和谐掩盖错误，则错误越拖影响越大，最后不可收拾，程序崩溃。[袁永福版权所有]

下面举个这条原则的例子，现数据库中有一个名为Customers的数据表，其内容如下：

对此笔者可以写出以下的两种代码来读取并输出其中的数据：

第一种：

1. using (IDbConnection conn = new OleDbConnection())  
2. {  
3.     // 连接数据库  
4.     conn.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" 
5.         + System.IO.Path.Combine(Application.StartupPath, "Customers.mdb");  
6.     conn.Open();  
7.     using (IDbCommand cmd = conn.CreateCommand())  
8.     {  
9.         // 设置SQL语句  
10.         cmd.CommandText = @"  
11.             Select   
12.                 CustomerID ,  
13.                 CompanyName ,  
14.                 ContactName ,  
15.                 ContactTitle ,  
16.                 Address ,  
17.                 City  
18.             From Customers";  
19.         // 读取并输出数据  
20.         IDataReader reader = cmd.ExecuteReader();  
21.         if (reader.Read())  
22.         {  
23.             Console.WriteLine("CustomerID  =" + reader["CustomerID"]);  
24.             Console.WriteLine("CompanyName =" + reader["CompanyName"]);  
25.             Console.WriteLine("ContactName =" + reader["ContactName"]);  
26.             Console.WriteLine("ContactTitle=" + reader["ContactTitle"]);  
27.             Console.WriteLine("Address     =" + reader["Address"]);  
28.             Console.WriteLine("City        =" + reader["City"]);  
29.         }//if  
30.         reader.Close();  
31.     }//using  
32. }//using 

 第二种：

1. using (IDbConnection conn = new OleDbConnection())  
2. {  
3.     // 连接数据库  
4.     conn.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" 
5.         + System.IO.Path.Combine(Application.StartupPath, "Customers.mdb");  
6.     conn.Open();  
7.     using (IDbCommand cmd = conn.CreateCommand())  
8.     {  
9.         // 设置SQL语句  
10.         cmd.CommandText = @"Select *  From Customers";  
11.         // 读取并输出数据  
12.         IDataReader reader = cmd.ExecuteReader();  
13.         if (reader.Read())  
14.         {  
15.             Console.WriteLine("CustomerID  =" + reader["CustomerID"]);  
16.             Console.WriteLine("CompanyName =" + reader["CompanyName"]);  
17.             Console.WriteLine("ContactName =" + reader["ContactName"]);  
18.             Console.WriteLine("ContactTitle=" + reader["ContactTitle"]);  
19.             Console.WriteLine("Address     =" + reader["Address"]);  
20.             Console.WriteLine("City        =" + reader["City"]);  
21.         }//if  
22.         reader.Close();  
23.     }//using  
24. }//using 

 这两种代码的唯一的区别就在于其中使用了不同的SQL语句，第一种代码使用的SQL语句是

而第二种代码使用的SQL语句是

第一种SQL语句字符比较多，开发者比较懒的话很容易写出第二种SQL语句。不过笔者推荐使用第一种SQL语句，因为第一种SQL语句符合尽早暴露程序错误的原则。[袁永福版权所有]

如果当数据库没有问题，则两种SQL语句都能执行，程序都能正确的读取数据，此时第二种写法反而貌似不错。

不过实际中应用程序开发和运行环境很复杂，比如发生了代码中字段名拼写错误、数据库字段结构发生改变，这些都是需要考虑到的问题。

例如数据表[袁永福版权所有]Customers中的字段Address由于某种原因删掉了，于是这两种代码都会发生错误。

对于第一种代码，程序会在执行代码“IDataReader reader = cmd.ExecuteReader();”时就会爆出异常“至少一个参数没有指定值 OleDbException”。此时开发者借助VS.NET可以很快的确定出发生错误的代码，并根据错误提示很容易猜测SQL语句写错了。于是开发者进行SQL语句与数据库结构的对比，很快就能发现错误的本质，那就是字段Address突然没了。

而对于第二种代码，程序顺利的执行了代码“IDataReader reader = cmd.ExecuteReader();”,但在执行代码“Console.WriteLine("Address     =" + reader["Address"]);”时爆出异常“Address IndexOutOfRangeException”。对于这个错误，开发者首先会有些迷惑，不知为什么发生错误，因为错误提示信息和数据库联系不大，而后怀疑代码中的“reader["Address"]”出现字段名拼写错误，花上一段时间仔细校对确定无误后才会往前继续寻找错误的来源，会发现SQL语句没有拼写错误，最后才会想到去查数据库结构，绕了半天才发现数据库字段Address没了，这才是错误的本质。

在这个例子中，数据库字段Address删掉的那一刻起，系统就存在隐患，而第一种代码能在第一时间由于这个隐患而爆出错误，而开发者就能立即定位到离隐患最近的代码，得到跟隐患密切相关的错误提示信息，也就能非常快的发现问题的本质，从而解决问题。这是一种将错误扼杀在摇篮当中的做法，对开发者对程序都有好处。[袁永福版权所有]

而第二种代码很和谐，没能在第一时间让隐患爆出错误，让隐患养着更肥，一直默默的影响着程序的运行，最终隐患爆出更大的更让人摸不着头脑的错误，使得开发者需要花费更多的时间精力来处理这个错误，这是姑息隐患，将错误养大了出栏再杀的做法，对开发者对程序都有害处。

在VB中有一个写作“On Error Resume Next”的语句，号称能和谐掉程序中所有的错误，让程序不爆出任何异常，丫就彻彻底底的破坛子破摔、掩耳盗铃的做法，因此这种写法应用得比较少。

因此开发者要写出一个真正和谐的程序，其过程必然不能简单粗暴的和谐，要尽可能早的让各种隐患爆出程序错误；隐患要上访变成错误，程序不能打击压制，而且程序要疏通各种隐患上访的通道，让开发者更快的发现错误的本质，更快的解决错误。尊重科学规律，正视隐患和错误，正确处理错误而不是打压隐患，程序才能和谐健壮。

嘿嘿，人类社会又何尝不是这样啊。[袁永福版权所有]

     本文转自xdesigner 51CTO博客，原文链接：http://blog.51cto.com/xdesigner/652695，如需转载请自行联系原作者