Best Practices for handling exceptions

(原文时间 September 18, 2007)
原文地址
 

(1)本文将会说明一些当你在处理异常时的最优方法.

Exception是一个很昂贵的进程,你使用异常只是在例外的情形和不受控制的规则逻辑流程时,
(Exception is an expensive process, for this reason, you should use exceptions only in exceptional situations and not to control regular logic flow.)
For example:

void EmpExits ( string EmpId)
{
    //... search for employee
    if ( dr.Read(EmpId) ==0 ) // no record found, ask to create
    {
        throw( new Exception("Emp Not found"));
    }
}

最优方法是:

bool EmpExits ( string EmpId)
{
    //... search for Product
    if ( dr.Read(EmpId) ==0 ) // no record found, ask to create
    {
        return false

    }
}

避免execption操作内部循环,如果它实在的需要执行try/catch 块环境下的循环就只有使用.

通常使用操作使用Try,catch,finally块的方式,这推存方法在非托管代码下操作错误条件异常.Finally块中要在异常的事件处理前确保资源被关闭.

SqlConnection conn = new SqlConnection("...");
try
{
    conn.Open();
    //.some operation
    // ... some additional operations
}
catch(¦)
{
    // handle the exception
}
finally
{
    if (conn.State==ConnectionState.Open)
    conn.Close(); // closing the connection
}

在这里任何可能使用代码验证的就能避免不需要的异常,如果你知道一个特别的条件能避免的异常发生或正好写代码能避免它.例如Object/变量之前确定任何校验操作为空,那Object/变量这个操作就应该注意到避免使用异常.

For example:

double result = 0;
try
{
    result = firstVal/secondVal;
}
catch( System.Exception e)
{
    //handling the zero divided exception
}

下面的就比上面的代码好

double result = 0;
if(secondVal >0)
result = firstVal/secondVal;
else
result = System.Double.NaN;

不需要重新去抛出异常,因为使用throw的去重新throw当前异常是创建一个新的异常的花费大约是相同,并且重新抛出异常还要确定非常困难的调式代码.

For example:

try
{
    // Perform some operations ,in case of throw an exception
}
catch (Exception e)
{
    // Try to handle the exception with e
    throw;
}

这里推存的方法是操作不同的错误在不同的执行连续的catch声明.这只是为让你的程序更明确,更广泛,例如操作文件陈述异常最好就是catch,
FileNotFoundException, DirectoryNotFoundException, SecurityException, IOException, UnauthorizedAccessException 最后是 Exception.


(2).NET errors should be capture through SqlException or OleDbException

    * 使用ConnectionState 属性为校验是否是连接状态,用来代替一个异常.
    * 使用Try/Finally更常见的是,finally提供关闭连接的选项和使用连接状态提供的功能是一样的.
    * 使用明确的操作捕获明确的异常,在很少的情形下你知道会有可能明确的错误,如数据库描述的错误它到底捕获的是SqlException还是OleDbException 如下:
    try
{ ...
}
catch (SqlException sqlexp) // specific exception handler
{ ...
}
catch (Exception ex) // Generic exception handler
{ ...
}

推存使用 微软提供的"Exception Management Application Block",它是简单和可扩张framework,是为搬动异常信息到时间日志中,或则你能定制写异常信息到其他的数据元中,要还没有令人心动,要更多的应用程序代码和工具的最佳方式和测试在Microsoft Lab.

------------------worksguo(翻译)-------------------------------------


大家好,翻译有什么问题请指正,下面是关于Exception Management Application Block的一些文章地址留给大家.


(国内的见解)http://blog.csdn.net/Cavingdeep/archive/2004/12/08/208909.aspx
(比较老的一篇文章)http://www.code-magazine.com/Article.aspx?quickid=0211131
(这篇还很不错)http://www.c- sharpcorner.com/UploadFile/sragavan/CustomExceptionsUsingMSExpBlock11142005070356AM/CustomExceptionsUsingMSExpBlock.aspx
http://blogs.msdn.com/adamga/archive/2004/03/08/86245.aspx
(有很不错的Sample)
http://www.pcreview.co.uk/forums/thread-1225798.php(这里是讨论)
(Msdn)http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/ehab.asp
接着就是说一下Exception Management Application Block的工作过程,其实是很简单的,看图

图上有标有数字:
1:程序抛出异常时,原于BaseApplicationException类,这个类提供Exception Management Application Block,
2:程序调用ExceptionManager类的Publish方法.
3:ExceptionManager类使用ExceptionManagerSectionHandler类重新获得应用程序的异常管理设置.
4:异常管理设置在应用程序的设置文件中,读取这个文件确定怎样发布异常.
5:如果在应用程序中没有异常设置, 异常将使用DefaultPublisher类被发布在windows Events Log,如果应用程序已经有异常管理配置,将发布在配置中的地址,所以包括DefaultPubisher类和普通发布类,都是被使用发布异常.所有的发布者都要继承最后在集合中的接口.
6如果一个异常发生在正在发布到一个定制异常(custom Publisher)时候,异常管理添加一个CustomPublisherException,并使用默认发布者发布它到Windows Event Log中.

如果要深入学习就可以到上面的地址中去！