将 ELMAH 日志 ID 传递到 ASP.NET 中的自定义错误页面时出现问题
我正在使用 ELMAH 来记录 ASP.NET Webforms 应用程序中未处理的异常。日志记录工作正常。
我想将 ELMAH 错误日志 ID 传递到自定义错误页面,该页面将使用户能够向管理员发送有关错误的电子邮件。我已遵循此答案。这是我的 global.asax 代码:
void ErrorLog_Logged(object sender, ErrorLoggedEventArgs args)
{
Session[StateKeys.ElmahLogId] = args.Entry.Id;
// this doesn't work either:
// HttpContext.Current.Items[StateKeys.ElmahLogId] = args.Entry.Id;
}
但是,在自定义错误页面上,会话变量引用和 HttpContext.Current.Items 给了我一个 NullReference 异常。如何将 ID 传递到我的自定义错误页面?
I am using ELMAH to log unhandled exceptions in an ASP.NET Webforms application. Logging is working fine.
I want to pass the ELMAH error log id to a custom error page that will give the user the ability to email an administrator about the error. I have followed the advice from this answer. Here is my global.asax
code:
void ErrorLog_Logged(object sender, ErrorLoggedEventArgs args)
{
Session[StateKeys.ElmahLogId] = args.Entry.Id;
// this doesn't work either:
// HttpContext.Current.Items[StateKeys.ElmahLogId] = args.Entry.Id;
}
But, on the Custom error page, the session variable reference and HttpContext.Current.Items are giving me a NullReference exception. How can I pass the ID to my custom error page?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这对我有用:
This works for me:
无法评论罗尼的解决方案。我已经这样做了一段时间,但它破坏了标准错误流程并导致 ErrorLog_Logged 始终传输,即使在调用
Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
时也是如此如果您仍然想在 catch 语句中记录错误,例如您有错误的解决方法,但希望记录错误以执行正确的修复,这对于难以复制的问题非常有帮助。
我能够通过使用以下更改来纠正此问题:
这正确地尊重了典型的错误处理,因为在您在 Elmah 中显式引发异常的情况下 context.Error 将为 null,但在通过默认错误处理时则不为 null (不是通过捕获或捕获并重新抛出)。这导致 Ronnie 的解决方案做出类似于 .Net 错误处理逻辑的响应。
Unable to comment on Ronnie's solution. I had that in place for a while but it breaks the standard error flow process and causes ErrorLog_Logged to always transfer, even when calling
Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
This is a problem if you still want to log an error from within a catch statement, for instance you have a workaround for an error but want to log the error to perform a proper fix, which can be pretty helpful on difficult to replicate issues.
I was able to correct this by using the following change:
This respects the typical error handling properly, as the context.Error will be null in cases where you explicitely raise the exception in Elmah, but is not null when falling through default error handling (not via a catch or if caught and re-thrown). This causes Ronnie's solution to respond similar to the .Net error handling logic.