如何在异常处理代码中处理异常？答案

【问题标题】：How to handle an exception within exception handling code?如何在异常处理代码中处理异常？
【发布时间】：2009-11-18 12:04:49
【问题描述】：

我的 Web 应用程序中有一些代码来处理未处理的异常 - 它会移交给记录详细信息的精美自定义错误页面。但是如果自定义错误页面中有未处理的异常怎么办？

我可以通过检查Request.CurrentExecutionFilePath 是否等于我的自定义错误页面，在我的常规异常处理程序中检测到这种情况，从而采取措施避免循环。但是有什么想法应该是这些步骤 - 退回到黄屏死机，切换到静态自定义错误页面？

或者我应该将我的自定义错误页面代码包装在 try {...} catch {} 中并停止担心吗？

【问题讨论】：

任何异常记录代码本身都应该放在 try{ } catch(Exception ex) { //do nothing here } empty catch 块中。有时，异常日志代码中可能会发生“疯狂的事情”。

标签： c# asp.net exception-handling

【解决方案1】：

我会使用 .nets 自定义错误框架并将静态 html 文件设置为 500 错误的目标。让自定义 500 页面执行任何可能失败的操作是个坏主意，因为它可能已经有任何 io 命令失败（例如数据库或文件访问）。

最好将自定义 500 页面保留为简单的 html 文件，并通过应用程序 global.asax 中的 Application_Error 事件记录所有异常，允许抛出异常，然后使用 .net 自定义异常处理程序提供您的自定义页面.

编辑：这是有关上述模式的相关文章。请注意，唯一的区别是我将使用静态 html 500 页面

http://devhood.com/tutorials/tutorial_details.aspx?tutorial_id=237

【讨论】：

【解决方案2】：

将您的自定义错误代码页包装在 try{...} catch{doSomethingThatCannotPossiblyFail()} 构造中。

【讨论】：

假设后来有人出现并忽略了文件中的所有 cmets，并添加了一些可以在 catch{...} 块中或在 try{...} 块之外引发异常的代码抓住{...}。也许我想防御这种可能性的想法太过分了......
这种方法的问题是，如果异常已经到了这一步（即 500 页），那么唯一可能的想法就是在这个阶段吞下异常，即从来不是一个好主意。仅记录探险远比使用自定义 500 页面通知用户失败要好得多
jdt199：这就是为什么我的回答中的 catch 块不是空的；-) 完全吞咽是个坏主意，同意。
noj：对于愚蠢没有万无一失的防御措施。在某些时候，您应该放弃并让服务器完成 500。过多的异常处理使得测试异常处理程序变得非常困难。

【解决方案3】：

老实说，这完全取决于您的日志记录机制的易变性，以及您希望记录每个错误的程度。您的日志记录总是有可能失败，因为它基于您的程序工作之外的某些东西（例如，数据库可用，可以访问日志文件，事件日志未满等）。如果没有其他原因来防止向用户显示巨大的令人讨厌的错误，您绝对应该将您的日志记录在 try catch 块中。

就个人而言，我会设置多个日志记录路径。第一个可能是数据库（虽然我个人不喜欢将错误记录到数据库，我更喜欢日志文件），第二个是事件日志，同时尝试发送一封电子邮件说明有问题。没有确切的方法可以说我对外部源的日志记录绝对不会失败，但您可以最大限度地减少这种可能性，并确保无论发生什么最终用户都不会看到灾难性的失败错误。

【讨论】：