【问题标题】:ASP.Net C# 4.0 - How to catch application thread exceptionsASP.Net C# 4.0 - 如何捕获应用程序线程异常
【发布时间】:2014-12-04 13:04:53
【问题描述】:

我有一个具有自定义内部线程的 ASP.Net 网站,用于定期执行的任务。

如果我在其中一个线程上遇到异常,它不会被 Global.ASAX 的 Application_Error() 函数捕获。它被允许冒泡到 IIS,我通过查看事件查看器日志来了解它。如果我发现异常,那么 Log4Net 会向我发送一封电子邮件,我应该会相对较快地发现错误。

有没有办法在这些线程上捕获异常?该应用程序需要“始终在线”,因此丢弃该应用程序的异常是一个显示停止器。

【问题讨论】:

  • 我认为理想的方法是从 Web 应用程序中完全删除定期运行的后台任务,并将它们移动到 Windows 服务或计划的控制台应用程序之类的东西上。然后,您可以在那些更适合长时间运行的后台任务的应用程序主机上处理异常。
  • 是的,虽然有点重写。必须有某种方法来捕获不是请求线程异常的线程异常?
  • 这里似乎有一些很好的信息:stackoverflow.com/q/186854/328193 我认为除了将关注点分离到适当的应用程序主机之外,最好的建议是确保线程不会抛出未处理的例外。每个线程可能都有一个顶级“worker”代码块,它应该捕获所有异常并将它们传达回父线程。不过,我认为您会遇到的问题是通信机制。什么网络应用程序中的父线程?它真的不适合后台线程。
  • 同意,例外是不好的。我正在使用 MySQL,偶尔(最多一个月一次)我会遇到数据库异常。这是一个严重错误,必须停止应用程序,强制注意并重新启动。我正在寻找以我的方式发送该错误,以便我可以进行干预。现在,我将数据库交互包装在 try-catch 块中,并希望 log4net 存在足够长的时间来给我发邮件。
  • 听从 David 的建议,创建一个 Windows Server 或类似的东西。我不得不清理在几个大型网站上启动线程的混乱,只是不要这样做,您的后台线程可能会关闭您的整个网站。

标签: asp.net multithreading exception


【解决方案1】:

在您提到的评论中:

这是一个网站而不是网络应用程序。

“网站”与“网络应用程序”在这一点上似乎是一个没有实际意义的区别。代码中有足够的复杂性,几乎可以对这个词的任何定义来说它都是一个“应用程序”。到那时,如果应用程序主机没有为您有意义地管理线程故障(我不希望 Web 应用程序主机这样做),那么您必须手动管理它们。

在这种情况下,我认为这是两个选项之一:

选项 1:不要让您的线程以故障状态结束。无论您的任何给定线程的顶级工作项是什么(在线程开始时调用的方法,循环重复操作等),都需要本质上是防错的。没有例外应该超越这一点。这意味着它需要非常简单(以免自己抛出异常),并且需要从它调用的操作中捕获任何和所有异常。

一旦被抓住,就随心所欲地处理它们。回滚工作单元,将错误通知某人等。

选项 2: 将长时间运行的线程操作移出 Web 应用程序,因为 Web 应用程序并不真正适合正在进行的后台进程。 Windows 服务或计划的控制台应用程序是更适合该逻辑的应用程序主机。

是的,不过这里有点重写。

是吗?不应该。这实际上是代码最初是如何架构的问题,与应用程序主机本身无关。从一个应用程序主机调用业务操作与从另一个应用程序主机调用它是一样的。如果逻辑与应用技术紧密耦合,那就是一个单独的问题。并且没有快速解决该问题的方法。好消息是,一旦你解决了那个问题,其他问题(比如提示这个问题的问题)都可以快速解决。

【讨论】:

  • 好的,今天我已经将所有的应用程序代码塞进了一个单独的程序集中,现在我使用预热缓存技术来启动应用程序,而不是使用 poke scipt 的 onDemand 方法。因此,该站点是一个准服务,因为 IIS 保持它始终运行。我将不得不爬取代码以防可能暴露于未捕获的数据库故障,并花一些时间打开和关闭数据库。乐趣。感谢您的帮助。
猜你喜欢
  • 2015-06-19
  • 2017-04-24
  • 1970-01-01
  • 1970-01-01
  • 2011-09-26
  • 2015-03-14
  • 2010-12-27
  • 1970-01-01
相关资源
最近更新 更多