C#书写规范(3)

（网上整理，感谢原作者）

五、异常处理

异常处理的原则

在应用程序级（线程级）错误处理器中处理所有的一般异常。遇到“意外的一般性错误”时，此刻错误处理器应该捕捉异常，给用户提示消息，在应用程序关闭或用户选择“忽略并继续”之前记录错误信息。

不必每个方法都用try-catch，当特定的异常可能发生时才使用。比如，当写文件时，处理异常FileIOException。

别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。这将有助于找出哪一段代码产生异常，并给用户发出特定的错误消息。

如果应用程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于IApplicationException。

在开发阶段，不必在所有方法中捕捉一般异常。刻意的放纵异常，将帮助在开发周期发现大多数的错误。

异常处理的提示

不要捕捉了异常却什么也不做，看起来系统似乎在正常运行。如果这样隐藏了一个异常，将永远不知道异常到底是否发生，为什么发生。

发生异常时，给出友好的消息给用户。但要精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。

永远别用像“应用程序出错”，“发现一个错误”等错误提示消息，而应给出类似“更新数据库失败，请确保登陆id和密码正确。”之类的具体消息。

显示错误消息时，还应提示用户如何解决问题。如：“更新数据库失败，请确保登陆id和密码正确。”，而不是仅仅说“更新数据库失败”。

显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。

异常处理的代码实例

推荐如下异常处理模式：

void ReadFromFile ( string fileName )

{

   try

   {

    // 读文件.

   }

   catch (FileIOException ex)

   {

    // 记载异常日志

    // 重抛具有针对性的异常信息

    throw;

   }

}

 

不推荐如下的异常处理模式：

void ReadFromFile ( string fileName )

{

   try

   {

    // 读文件

   }

   catch (Exception ex)

   {

    // 捕捉一般异常将让我们永远不知道到底是文件错误还是其他错误

    // 隐藏异常将我们永远不知道有错误发生。

    return "";

   }

}

 

六、对象实例的申请与释放

.Net平台的垃圾回收机制，可以自动的dispose不再引用的对象实例，所以很多开发人员并不主动释放申请的对象资源。事实上，在对象的生命周期结束之前是不会被释放的。

但是，很多时候当对象处于生命周期之内时，我们不再使用它，以便释放资源提升系统效率。因此，主动释放申请的资源显得很有必要。

永远不要把力所能及的事情交给操作系统，及时释放不再使用的资源是一个好习惯。

七、数据库访问

数据库访问永远是系统的瓶颈，选择高效、稳健的数据库访问模式是产品性能的基础保证。

永远不要假设你的应用系统构建与某个数据库之上，因此必须有统一的、透明的数据库访问机制。

采用ADO.Net访问数据库。基于效率和稳定性的考量，采用微软平台原生的数据库访问模式ADO.Net。使用ADO.Net可以通过OLEDB和ODBC两种模式访问数据库，我们建议使用数据库厂商提供的OLEDB模式，这种模式绕过了ODBC，使得数据库的游标性能大大提升，效率更佳。

不使用第三方的数据持久层。使用类似于Nhibernate之类的第三方数据持久层工具虽然可以提高开发的效率，但是却降低了系统的性能和弹性。性能对于产品而言，远远比开发效率重要的多，况且基于VS2005的开发，效率不是问题。请记住：第三方的工具永远不能成为你的产品核心技术；数据访问机制是系统的效率瓶颈，对

使用自主产权的数据对象。直接采用ADO.Net封装最底层的数据访问方法：插入、删除和更新，以及事务管理等；客户端和服务器端采用相同的数据访问机制，并设立连接缓冲池提升数据访问效率。

八、分布式事务管理

对于多层分布式应用而言，数据库事务呈现出“远程、分布”的特色，导致事务难以管理。

对于Ado.Net而言，事务绑定了数据库连接，因此必须在数据访问对象中对每一个数据库连接管理各自的事务或嵌套事务。如果要访问数据库，服务器上的数据访问对象将自动分配一个特定的连接，根据该连接ID执行数据操作；无论该事务分布于多少个远程客户端进程，服务器数据对象只需要锁定连接ID即可轻松进行事务管理。