在c# om nom nom中使用异常

Question

考虑到吃异常总是很糟糕，重新抛出异常会丢失调用堆栈，那么重构以下代码的正确方法是什么呢？

饮食异常：

try
{
  … do something meaningful
}
catch(SomeException ex)
{
   // eat exception
}

Answer 1

try
{
 ...
}
catch(SomeException e)
{
 //Do whatever is needed with e
 throw; //This rethrows and preserves call stack.
}

Answer 2

捕获和处理特定类型的异常。好的做法是捕获而不是，只捕获System.Exception即可。一个健壮的例程将强烈地键入它知道如何处理的异常。

异常不应该用于控制流，但通常需要根据异常的类型执行特定的展开过程。

根据具体的类型，您可能会选择重新抛出它，也可能不会。例如，向使用导致异常的代码的错误页抛出ASP分析异常将导致无限循环。

try
{

}
catch( FileIOException )
{
    // unwind and re-throw as determined by the specific exception type
}
catch( UnauthorizedAccessException )
{
    // unwind and re-throw as determined by the specific exception type
}
catch( SomeOtherException )
{
    // unwind and re-throw as determined by the specific exception type
}
catch( Exception )
{
   // log and re-throw...add your own message, capture the call stack, etc.

   // throw original exception
   throw;

   // OR, throw your own custom exception that provides more specific detail and captures
   // the original exception as the inner exception
   throw new MyStronglyTypedException();
}
finally
{
     // always clean up
}

Answer 3

大多数人认为吃掉/抑制异常是完全不好的，特别是对于所有的异常。(具有讽刺意味的是，他们使用catch all响应“不要使用catch-all，它是邪恶的”:-)。我不理解人们对这种观点的宗教狂热，因为如果明智地使用，这种方法没有什么错。

• 在我的书中，最坏的情况是我的程序灾难性地退出->，这会产生一个非常不满意的客户，出现完全数据丢失的情况。未处理的异常保证每次都会导致这种情况。因此，在统计上，无法处理异常比抑制异常时可能发生的任何不稳定风险更危险。有鉴于此，我们可以合理地做任何事情来防止未处理的异常发生是一件好事。
• 许多人似乎忘记了catch all通常可以正确处理任何异常，即使他们不知道异常的细节。我的意思是，它们可以保证程序状态保持稳定，并且程序继续在其设计参数内运行。或者甚至可能会有副作用，比如用户发现按钮没有响应，但它们仍然不会丢失任何数据(即优雅的降级比致命的崩溃更好)。例如，有时您希望在成功时返回一个值，如果由于任何原因而失败，则返回一个默认值。设计代码的一部分是知道什么时候向用户报告错误，什么时候代表他们修复问题，以便他们的程序“正常工作”。在这种情况下，一个设计良好的通用工具通常是job.
• Exceptions的正确工具。从根本上说，如果我不处理它，异常肯定会导致程序崩溃。如果我只为我期望的异常添加特定的异常处理，我的程序本质上是脆弱的。想想它有多容易被破坏：

- If a programmer forgets to document one exception they might throw, I won't know I need to catch it, and my code will have a vulnerability I'm not aware of.
- If someone updates a method so that it throws a new exception type, that new exception could ripple up the call stack until it hits my code. But my code was not built to handle the exception. Don't tell me that the libraries I'm calling will never change.
- Every exception type you specifically handle is another code path to be tested. It significantly multiplies the complexity of testing and/or the risks that a broken bit of handling code might go unnoticed.

​

• 支持“抑制是邪恶的”观点的观点是，所有异常都代表不稳定或错误-但在许多情况下，程序员使用异常返回的只是状态信息。例如，FileNotFound。编写文件I/O代码的程序员代表我决定，文件丢失是一个致命错误。有可能是这样。这取决于我来捕捉到这一点，并决定这实际上是一种常见的、完全正常的或预期的情况。很多时候，为了阻止其他人的“决定”删除我的应用程序，有必要抑制异常。简单地忽略错误返回代码的旧方法并不总是一件坏事，特别是考虑到捕获和抑制大量流传的“状态”异常需要付出大量的努力。

默默地吃/抑制异常的诀窍就是确保这是正确的处理方法。(在许多情况下，情况并非如此)。所以可能没有必要重构你的示例代码--它可能不是一个糟糕的juju。