问题标签 [exception]

我正在维护一个 .NET 1.1 应用程序，我的任务之一是确保用户看不到任何不友好的错误通知。

我已经向Application.ThreadExceptionand添加了处理程序AppDomain.CurrentDomain.UnhandledException，它们确实被调用了。我的问题是仍然显示标准 CLR 错误对话框（在调用异常处理程序之前）。

Jeff 在他的博客here和here上谈到了这个问题。但是没有解决办法。那么.NET 1.1 中处理未捕获异常和显示友好对话框的标准方法是什么？

Jeff 的回答被标记为正确答案，因为他提供的链接包含有关如何执行所需操作的最完整信息。

将 rails 1.2 网站升级到 2.1 后，ExceptionNotifier 插件不再工作，抱怨此错误：

ActionView::TemplateFinder::InvalidViewPath：找到未处理的视图路径：“/path/to/appname/vendor/plugins/exception_notification/lib/../views”。使用#append_view_path、#prepend_view_path 或#view_paths= 设置视图路径。

是什么原因造成的，我该如何解决？

C++ 中的异常不需要被调用函数捕获（没有编译时错误）。因此，是否使用 try/catch 捕获它们取决于开发人员的判断（与 Java 不同）。

有没有一种方法可以确保调用函数始终使用 try/catch 捕获抛出的异常？

我从来没有对异常处理的工作方式完全满意，有很多异常和 try/catch 带来的表（堆栈展开等），但它似乎在这个过程中破坏了很多 OO 模型。

无论如何，这是问题所在：

假设您有一些类包装或包含网络文件 IO 操作（例如，在某处的某个特定 UNC 路径读取和写入某些文件）。由于各种原因，您不希望这些 IO 操作失败，因此，如果您检测到它们失败，则重试它们并继续重试它们，直到它们成功或达到超时。我已经有一个方便的 RetryTimer 类，我可以实例化并使用它在重试之间休眠当前线程，并确定超时时间何时结束，等等。

问题是你在这个类的几个方法中有一堆 IO 操作，你需要将它们中的每一个都包装在 try-catch / retry 逻辑中。

这是一个示例代码片段：

那么，如何避免为整个班级的每个文件 IO 操作重复大部分代码呢？我的解决方案是在执行传递给它的委托块的类中使用匿名委托块和单个方法。这让我可以用其他方法做这样的事情：

我有点喜欢这个，但它还有很多不足之处。我想听听其他人如何解决这类问题。

我有一个简单的属性设置方法，null不适合这个特定的属性。我一直在这种情况下被撕裂：我应该扔一个IllegalArgumentException，还是一个NullPointerException？从 javadocs 来看，两者似乎都是合适的。有某种可以理解的标准吗？或者这只是你应该做任何你喜欢做的事情之一，而且两者都是正确的？

因此，在 Java 中，构造函数的第一行必须是对 super 的调用……无论是隐式调用 super()，还是显式调用另一个构造函数。我想知道的是，为什么我不能在它周围放一个 try 块？

我的具体情况是我有一个模拟类进行测试。没有默认构造函数，但我想要一个使测试更易于阅读。我还想将从构造函数抛出的异常包装到 RuntimeException 中。

所以，我想要做的实际上是这样的：

但是 Java 抱怨说 super 不是第一个声明。

我的解决方法：

这是最好的解决方法吗？为什么Java不让我做前者？

对于“为什么”，我最好的猜测是 Java 不希望我的构造对象处于可能不一致的状态……但是，在进行模拟时，我不在乎。看来我应该能够做到以上...或者至少我知道以上对于我的情况是安全的...或者似乎无论如何都应该这样做。

我正在覆盖我在测试类中使用的任何方法，因此我没有使用未初始化变量的风险。

我多次遇到以下类型的代码，我想知道这是否是一种好的做法（从性能的角度来看）：

基本上，编码人员所做的是他们将异常包含在自定义异常中并再次抛出该异常。

这在性能上与以下两个有何不同：

或者

抛开任何功能或编码最佳实践论点，这 3 种方法之间是否存在性能差异？

我有一个应用程序进行前缀搜索一段时间。最近索引大小增加了，结果发现某些前缀太多，以至于 lucene 无法处理。它不断向我抛出一个Too Many Clauses错误，这让我非常沮丧，因为我一直在查看我的 JAR 并确认包含的代码实际上都没有使用布尔查询。

为什么它不抛出类似 Too Many Hits 异常的东西？当我肯定只使用前缀查询时，为什么增加布尔查询的静态最大子句整数实际上会使这个错误消失？查询的运行方式是否有一些我不理解的基本内容？是不是他们偷偷变成了布尔查询？

我有一个用 /clr 编译的 MFC 应用程序，我正在尝试为其他未捕获的托管异常实现最终处理程序。对于本机异常，覆盖CWinApp::ProcessWndProcException有效。

Jeff 的CodeProject 文章中建议的两个事件,Application.ThreadException和AppDomain.CurrentDomain.UnhandledException, 没有引发。

谁能建议一种为混合可执行文件提供最终托管异常处理程序的方法？

更新：

似乎这些异常处理程序仅在下游Application.Run或类似情况下触发（有工作线程风格，不记得名称。）如果您想真正全局捕获托管异常，则需要安装 SEH 过滤器。你不会得到一个System.Exception，如果你想要一个调用堆栈，你将不得不滚动你自己的助行器。

在有关此主题的 MSDN 论坛问题中，建议覆盖try ... catch (Exception^). 例如，CWinApp::Run. 这可能是一个很好的解决方案，但我没有研究过任何性能或稳定性影响。在保释之前，您将有机会使用调用堆栈进行日志记录，并且可以避免默认的 windows unahndled 异常行为。

我正在动态加载用户控件，将它们添加到 Web 表单的 Controls 集合中。

如果用户控件在渲染时导致未处理的异常，我想隐藏它们。

因此，我尝试连接到每个 UserControl 的 Error 事件，但似乎该事件永远不会像对 Page 类那样为 UserControls 触发。

做了一些谷歌搜索，它似乎并不乐观。这里有什么想法吗？