在捕获异常时仅记录异常是不好的做法吗？

Question

捕获异常并记录它是否有任何负面影响？这就像在每个异常捕获上完成的最低限度，但它并没有真正对异常做任何事情。

我相信这取决于具体情况，例如面向用户的异常需要一个弹出窗口等，但是后端的东西是用户看不到的，不是。或者可能还有更多内容。

Answer 1

一般来说，在每种情况下做正确的事情。有时，这意味着只记录异常。在其他情况下，您可以执行特定的目标恢复。

例如，如果用户请求您打开文件，然后捕获FileNotFoundException，则向用户报告此信息并为他们提供选择其他文件的机会是合适的。或者，如果解析用户提供的字符串会触发FormatException（尽管您经常使用 TryX 模式来避免此处的异常），请告诉用户输入数字字符串。

通常，最好的办法是根本不能捕获异常。如果你不能做任何适当的事情，那就让它冒泡到应用程序堆栈的根目录，在那里你可以记录它，或者经常让它崩溃你的应用程序。如果您不知道为什么会看到异常，您是否确定您的应用程序是健康的，并且不会损坏数据？

Answer 2

异常应该只在特殊情况下发生，或许可以查看是否可以重写代码以执行检查，然后执行导致抛出异常的操作，并记录检查结果是否失败。

您应该使用例外来追踪错误/通知用户他们的输入不正确/矩阵中有毛刺

Answer 3

我倾向于将异常传播到GUI级别，可以捕获它们。非常令人沮丧的是，知道异常被捕获并且您不知道它们发生的位置（没有堆栈跟踪）。

当您在框架内工作时，由于接口限制，有时无法传播Exception。在这种情况下，我将捕获异常并尝试确保我提供了日志消息中出现的类和方法。

Answer 4

有些例外情况表明情况非常糟糕，应用程序应尽快关闭以避免破坏系统;数据可以安全到恢复文件，但不应覆盖主文件。其他例外表明发生了意外但可恢复的情况。其他人表示微软省略了他们应该包含在API中的Try___方法（例如Control.TryBegininvoke）。在以前的情况下，吃异常会非常糟糕。在最后一种情况下，吃异常是获取工作代码的最简洁方法（确保Control.BeginInvoke不会抛出所需的变通方法是非常糟糕的，并且容易引起更多冲突，而不是吞噬来自BeginInvoke的异常）。在中间情况下，异常处理程序应该修复该情况，以便包含它的模块可以遵守其合同。如果可以做到这一点，则无需进一步传播异常。