c# 和捕获异常答案

【问题标题】：c# and catching exceptionsc# 和捕获异常
【发布时间】：2011-10-13 13:47:21
【问题描述】：

在处理异常时附加一个通用异常捕获是一种好习惯吗？一个例子可以让这个问题更清楚

try{
 // do something
}catch(spomespecificException1 ex){
 //logging and other stuff
}catch(spomespecificException2 ex){
 //logging and other stuff
}catch(Exception ex){
 //logging and other stuff
}

我应该将异常捕获附加到堆栈中

【问题讨论】：

这实际上取决于情况的上下文，并且可能也相当主观。如果没有更多细节，我认为你真的不能说是或否。
相关线程 - stackoverflow.com/questions/183589/…
我的一般经验法则是在会中止工作单元但让进程继续的点捕获一般异常。也就是说，如果我有一个订单处理服务，并且我正在下订单，我想捕捉下订单的任何异常，所以我不会关闭服务，但任何比这更深的东西都不应该被捕获和消费.在我看来，这与 John 的 Handle/Fix 定义一致。但那是我……
@JamesMichaelHare：你怎么知道关闭服务可能不是正确的事情？也许该服务已损坏，以至于当它不抛出异常时，它正在破坏订单。关闭服务（并通知您以便您尽快修复它）可能是正确的做法。
@John：这总是一种选择。但是，如果它同时取消当前正在处理的其他订单，也可能导致可怕的财务后果。我们向监控工具报告所有异常以及所有性能计数器，以便我们可以从仪表板查看应用程序的状态，包括抛出的异常。

标签： c# exception

【解决方案1】：

一般来说，您根本不应该捕获这些异常。不要捕获您实际上不知道如何处理的异常。

“处理”意味着修复。如果您无法解决问题，或者无法添加其他信息，请不要捕获异常。

【讨论】：

这不是真的。在很多情况下，您希望捕获异常以优雅地退出，通知用户或通知管理员。您只是希望异常不被处理，这种情况很少见。
为了记录目的而捕获呢？
@Tom：但在那种情况下，你正在处理它，否则你会抓住并重新抛出。我认为重点是永远不要使用您无法修复的异常（修复含义正确处理并继续）。
如果你必须捕获异常才能记录它，那么它应该尽可能靠近调用堆栈的顶部。而且，在许多情况下，框架会为您记录。例如，ASP.NET 就是这种情况。并确保您的日志记录能够触发 SCOM 或 Big Brother 等服务器监控工具。

【解决方案2】：

这取决于具体情况以及您想让异常在被捕获之前冒泡的堆栈高度。

肯定有赞成和反对的理由，但如果没有针对您的具体情况的详细信息，就不可能说出来。

那么，有没有关于它的一般“规则”？没有。

【讨论】：

我会争辩（并且经常这样做），一般规则是不要捕获异常，除非您知道如何处理它们，因此，一般来说，不要捕获异常。
@John Saunders 捕捉它们怎么样，这样你就可以抛出自己的自定义异常
@RichardBanks：当然，除了几乎不需要自定义例外。仅当调用者明确捕获您的异常时才使用它们。如果调用方代码对MyCustomException 的反应与对InvalidOperationException 的反应相同，则不需要MyCustomException。如果您只是想自定义Message，那么String.Format 会负责。
@John Saunders 不会创建自定义异常意味着更少的代码。如果一个方法必须处理 5 个异常，那么为什么不将抛出的异常包装在自定义异常中，那么调用者只需捕获一个自定义异常。
@RichardBanks：那为什么还要尝试捕获所有不同的异常类型，只捕获异常？

【解决方案3】：

如果您想要执行与该异常相关的一些特定处理，您发布的代码很好 - 您希望在其他 catch 块之一中执行此操作。一个很好的例子可能是当您尝试连接到 SQL 数据库时，您可以以不同的方式处理不同的错误消息。

另外，请记住，您可以在末尾添加一个“finally”块来执行所有清理（和通用）处理代码，但您不会在其中获得异常信息

【讨论】：

【解决方案4】：

通常会发生异常，尤其是当您访问应用程序外部的某些内容（例如连接错误等）时。

如果你想过滤掉异常的类型并对每种特定类型做不同的事情，那么这样做没有错。

更好的编码实践是首先防止这些异常发生。

【讨论】：