.Net应用程序错误
在 Global.asax 中，我在 Application_Error 处理程序中有代码，它将错误消息存储在 HttpRuntime.Cache 中，将错误记录到应用程序日志文件中，然后将用户转移到 Error.aspx 页面以在网站模板/主题中显示消息（通过从 HttpRuntime.Cache 检索它）。
我想知道是否有一个好的方法来管理 HttpRuntime.Cache 内容。
目前，我正在使用全局可用常量文件中定义的键设置 HttpRuntime.Cache 值，然后在后面的 Error.aspx 代码中显式删除它。
是否有更智能的方法来确保错误处理完成后正确清理 HttpRuntime.Cache？
从上下文中抽象：
MethodA 在中央存储位置设置一些值 控制权转移到 MethodB，该方法使用中央存储中的值 只有成功读取值后，方法B 才应从存储中清除值
。 限制：不能将控制权交还给方法A。一旦 MethodB 完成，程序就结束。
In Global.asax i have code in Application_Error handler which stores the error message in HttpRuntime.Cache, logs the error to the application log file and then Transfers the user over to the Error.aspx page to display the message within the website template/theme (by retrieving it from HttpRuntime.Cache).
What i want to know is if there is a good way to manage the HttpRuntime.Cache content.
Currently, i am setting the HttpRuntime.Cache value with a key that is defined in globally available Constants file, and then explicitly removing it in the Error.aspx code behind.
Is there a smarter way to ensure that the HttpRuntime.Cache is cleaned up properly once the error handling is complete?
To abstract from the context:
MethodA sets some values in a central storage location
Control is transferred to MethodB which uses the values from central storage
Only upon successfully reading the values, should MethodB clear the values from storage
Restriction: Control cannot be given back to MethodA. Once MethodB is complete, the program ends.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恕我直言，你走在正确的轨道上。
我以前做的就是有一个DTO（Data Transfer Object，轻量级数据对象），用来保存异常信息，保存在Session中。捕获错误并强制重定向到错误页面的代码还在 DTO 中设置一个标志来说明错误是否可恢复，如果可以，它还会在 DTO 中存储一个 URL - 这意味着错误页面可以呈现出供用户单击以返回到被中断的位置的链接（您可以控制该链接及其末尾的任何内容，因此您可以将它们发送回应用程序中您喜欢的任何位置，或者重新创建一个尽可能多地为他们提供页面 继续）。
请记住，缓存是全局的，因此您可以用另一个用户的异常信息覆盖一个用户的异常信息。
IMHO you are on the right track.
What I have done in the past is to have a DTO (Data Transfer Object, a lightweight data object) that is used to hold the exception information and is stored in Session. The code which catches the error and forces the redirect to the error page also sets a flag in the DTO to say whether the error is recoverable, and if so it also stores a URL in the DTO - this means the error page can render out a link for the user to click on to go back to where they were interrupted (you are in control of the link, and whatever is on the end of it, so you can send them back to whereever you like within your application, or recreate a page as much as you like for them to continue).
Remember that the Cache is global, so it is possible that you can overwrite one user's exception info with another user's.