拥有单一的,可能是常见的通用异常是不好的编程风格？

Question

所以在我的程序中我有部分我使用这样的try catch块

try
{
  DirectoryInfo dirInfo = new DirectoryInfo(someString); 
 //I don't know if that directory exists
 //I don't know if that string is valid path string... it could be anything

 //Some operations here
}
catch(Exception iDontCareWhyItFailed)
{
  //Didn't work? great... we will say: somethings wrong, try again/next one
}

当然我可能会检查字符串是否是有效路径(正则表达式),然后我会检查目录是否存在,然后我可以捕获各种异常,看看为什么我的例程失败并提供更多信息......但在我的程序中这不是必要的.现在我真的需要知道这是否可以接受,以及专业人士对此有何看法/想法.非常感谢您的关注.

Answer 1

• 编写"主线"代码来处理预期的情况.
• 编写异常处理代码...等待它... 处理异常情况.这就是为什么它被称为"异常处理代码".:-)

如果主线,预期的日常情况是路径不存在,则编写检查路径是否存在的主线代码.如果一个意外的,奇怪的,异常情况是该文件存在但已被另一个用户锁定,则编写一个处理该异常的异常处理程序.

Answer 2

您不应该使用异常进行流控制,因为它会影响性能,异常不是为此目的而设计的.相反,您应该测试该Exists属性以检查该目录是否存在

Answer 3

如果您确实不关心它失败的原因，并且您的程序无法合理地执行任何操作来恢复，那么可以这样做；我宁愿维护这样的东西，也不愿使用 3 个 try/catch 块来做同样的事情但不添加任何附加值的代码。我确实喜欢异常的名称，它表明它并不重要，这比捕获名为 的变量更好ex。

然而，一些建议：

1. 如果您要“捕获并忽略”，请更明确地说明哪些异常类型可以忽略。如果您知道可以忽略FileNotFoundException或 的任何类别IOException，那么就抓住它。

2. 如果您要捕获通用异常，请考虑将异常记录在某处。如果您的 try 块中存在逻辑缺陷，您当前的方法可能会成为维护噩梦。例如，假设您编写了一个关于数组索引的离一错误...您当前的代码将吞掉该错误，并且不会提供任何指示发生了比“目录不存在”更重要的事情。