在做了一些研究后，似乎AppDomains并不是构建托管服务器的真正工具。根据我的理解，如果在创建的AppDomain中存在未处理的异常（如果从创建的AppDomain中的线程抛出异常），托管服务器仍将崩溃。因此，在这种情况下，如果托管服务器托管一个泄漏异常的服务，这也会降低默认的AppDomain。
所以我想从服务器架构的角度来看，没有比创建子流程和监控它们更好的了。
这是正确的还是我错过了AppDomains的东西？
感谢， 克里斯托弗
答案 0 :(得分：2)
如果您可以控制在其他AppDomain中创建的线程，您还可以通过在线程main方法中使用catch-all块来处理异常。
除此之外，只要您使用默认主机，我相信您的假设是正确的。但是，如果您自己托管运行时，也可以处理未处理的异常。
嗯，这是可能的。你必须这样做 创建自己的CLR主机。那开始了 使用ICorBindToRuntimeEx（）。你得到 完全控制AppDomains 抛出异常。而且它正在存在 由ASP.NET和MS等MSFT软件使用 SQL Server 2005.当你写一个 服务，你正在与 默认CLR主机实现和它 任何时候终止进程 未处理的异常被提出， 无论AppDomain是什么造成的 例外。
问题是，像ASP.NET和SQL这样的主机 服务器有一个定义良好的代码 执行路径。在Web服务器中， 托管代码由于页面而运行 请求。在dbase服务器中，它运行 因为一个查询。什么东西 不好的事情，他们有奢侈的 简单地扼杀所有的东西 请求开始（杀死 AppDomain）并返回“抱歉， 无法做到这一点“回到了现状 客户。你可能已经看过了， 在旧的论坛服务器上崩溃 网站是相当微不足道的，但没有 阻止它提供其他请求。 实际上并非100％确定。
您的服务实施是 可能不是那么干净。我不能 告诉你，你没有说什么 它。一般来说，有一个问题 中止一个线程。你一直 当有一个时，必须中止一个线程 未处理的异常。一项服务 通常有一个线程，由...开始 OnStart（）方法。中止它 杀死服务器直到有人停止 并重新开始。
你绝对可以做得更多 比这更有弹性，你可以开始了 发起孩子的“主人”线程 线程响应外部事件 这使您的服务发挥作用。 让子线程终止 因为未处理的异常是 你有可能恢复的东西 从。但是，如果你接下来做的话 一步，为什么不拥有子线程 捕获异常并将其传递回 主线程所以它可以成为一个 关于做什么的明智决定 下。
默认CLR的冷酷事实 主持人是：如果你不愿意 处理失败，它不会 为你做的工作。它不应该， .NET 1.x对线程的行为 死于异常是一个主要的 在.NET中纠正的错误 2.0。
你知道该怎么做：处理失败。 或者写你自己的主人。或接受 事情可能超出你的控制范围 并记录一个很好的错误消息，以便您 可以告诉您的客户该做什么。 我强烈推荐后者。