(一)在什么场景下加Try-Catch机制

 

1)以业务逻辑功能为单位,在最上层加Try-Catch机制。为什么要这样做呢?这主要是增加程序的健壮性,防止因抛出异常过多,导致程序崩溃。

try

{
   //业务逻辑功能
   //......
}
catch (Exception ex)
{
   //记录日志
   //......
}
2)底层代码,在可能出错的地方加Try-Catch机制,用Catch侦测具体的异常,然后就具体的异常,采取相应的解决方案。
try

{
    sent += sendSAEA.AcceptSocket.Send(buffer, sent, size - sent, SocketFlags.None);
}
catch (ObjectDisposedException ex)    //Socket 已关闭
{
    break;
}
catch (SocketException ex)
{
    //socket异常,等待后继续尝试发送
    Thread.Sleep(this.socketListenerSettings.MSDelayForNextSend);
}
catch (Exception ex)
{
    this.SaveLog("Send方法出错,错误描述为:" + ex.Message.ToString());
    break;
}
3)底层代码,在需异常追踪时加Try-Catch机制,在Catch块中抛出自定义异常,调试时可迅速定位到错误代码段。
try

{
    //底层代码
    //......
}
catch (Exception ex)
{
    throw new Exception("xxx方法出错,描述:" + ex.Message.ToString());
}

(二)Try-Catch机制注意点

1)Try-Catch机制会将异常屏蔽掉,在解决异常时,您可以根据具体的异常执行相应的解决方案,也可以记录错误日志,用于异常追踪,还可以直接抛出自定义异常。在众多选择中,请牢记一条:必须根据具体的应用场景,具体分析。比如,我们写一个程序实现ATM机取现功能,首先,验证用户的合法性,其次,验证用户本次操作的合法性,最后,完成用户操作。我们在以上三个操作都加上Try-Catch机制,如果此时第一个操作出现异常,您如果只是记录一下日志,将此异常屏蔽掉,将会造成灾难性的后果。

2)不能滥加Try-Catch机制,Try-Catch机制在一定程度上会损耗或影响性能,建议有以下几点准则:
  1.尽量给CLR一个明确的异常信息,不要使用Exception去过滤异常

  2.尽量不要将try…catch写在循环中

  3. try尽量少的代码,如果有必要可以使用多个catch块,并且将最有可能抛出的异常类型,书写在距离try最近的位置

  4.不要只声明一个Exception对象,而不去处理它。这样做白白增加了Exception Handing Table的长度。

  5.使用性能计数器实用工具的“CLR Exceptions”检测异常情况,并适当优化

  6.使用成员的Try-Parse模式,如果抛出异常,那么用false代替它

05-11 17:01