C#错误处理catch块

Question

为什么大多数时候我们不建议我们不应该捕获像"异常"这样的错误,而是要捕获我们期望作为开发人员的错误.在捕获一般性错误方面是否有性能损失,还是从最佳实践角度推荐？

  try
  {
        // Do something
  }
  catch(Exception e)
  {
        //Log error
  }

Answer 1

最佳实践是首先捕获特定的异常,然后转向更通用的异常.

异常处理(C#编程指南)

具有不同异常过滤器的多个catch块可以链接在一起.catch块在代码中从上到下进行计算,但是对于抛出的每个异常只执行一个catch块.执行指定抛出异常的确切类型或基类的第一个catch块.如果没有catch块指定匹配的异常过滤器,则选择没有过滤器的catch块(如果语句中存在一个).首先使用最具体(即派生最多)的异常类型定位catch块非常重要.

对于你的问题:

为什么大多数时候我们不建议我们不应该捕获像"异常"这样的错误,而是要捕获我们期望作为开发人员的错误.

一个例子是捕获NullReferenceException.从来没有一个更好的做法来捕获NullReferenceException,而应该始终在使用其实例成员之前检查对象是否为null.例如,在字符串的情况下.

string str = null;
try
{
   Console.WriteLine(str.Length)
}
catch(NullReferenceException ne)
{
    //exception handling. 
}

相反,应该有一个检查来检查null.

if(str != null)
   Console.WriteLine(str.Length);

编辑:

我认为我的问题是错误的,如果你问的是哪个例外应该被捕获,哪个不应该被IMO捕获,那些可以处理的异常应该被捕获并且休息应该保留在库中以便它们可以冒泡到上层将进行适当处理的层.一个例子是违反主键约束.如果应用程序正在从用户那里获取输入(包括主键)并且该日期正被插入到数据库中,则可以捕获该异常并向用户显示消息"Record already exists"然后让用户输入一些不同的价值.

但是,如果异常与外键约束相关(例如,下拉列表中的某些值被视为无效外键),则该异常应该冒泡,并且通用异常处理程序应将其记录在适当的位置.

例如,在ASP.Net应用程序中,可以在Application_Error事件中记录这些异常,并且可以向用户显示常规错误页面.

编辑2: 对于OP的评论:

如果在低级别,如果在捕获一般错误时会出现性能下降,尽管知道错误是否为sqlexception

即使存在性能差异,也应该可以忽略不计.但是抓住特定的异常,如果你知道异常就会被SqlException捕获.