相关疑难解决方法(0)

注意:这不是Jeff的问题的重复.

那个问题问"是等同的吗？" 我知道没有,我想知道为什么!

我问的原因是我只是清楚它有多重要,结论对我来说似乎很奇怪.

Microsoft企业库的异常处理块建议我们使用此模式:

catch (Exception x)
{
    if (ExceptionPolicy.HandleException(x, ExceptionPolicies.MyPolicy))
        throw;

    // recover from x somehow
}

该策略是在XML文件中定义的,这意味着如果客户遇到问题,我们可以修改策略以帮助跟踪(或者可能还有问题)以便快速解决问题,直到我们正确处理它为止. - 这可能涉及与第三方争论,关于谁的错.

这基本上是对一个简单事实的承认,即在实际应用中,如果没有这样的设施,实际上就无法管理异常类型的数量及其"可恢复性"状态.

与此同时,MS的CLR团队表示这不是一个选择,事实证明这些人知道他们在谈论什么!问题是在catch块运行之前,finally嵌套在块内的任何块try都将被执行.所以这些finally块可能会执行以下任何操作:

• 无害地修改程序状态(phew,lucky).
• 在客户的数据中删除重要的东西,因为程序状态被搞砸到了未知程度.
• 伪装或破坏我们需要诊断问题的重要证据 - 特别是如果我们谈论调用本机代码.
• 抛出另一个例外,增加了一般的困惑和痛苦.

请注意,using语句和C++/CLI析构函数构建在try/上finally,因此它们也会受到影响.

很明显,过滤异常的catch/ throw模式并不好.实际需要的是一种通过策略过滤异常而不实际捕获它们从而触发finally块执行的方法,除非我们找到一个告诉我们异常可以安全恢复的策略.

CLR团队最近在博客上写了这篇文章:

• Catch,Rethrow和Filters - 你为什么要关心？
• 为什么catch(异常)/空捕获很糟糕

结果是我们必须在VB.NET中编写一个辅助函数,以允许我们从C#访问这个重要的功能.存在问题的一个重要线索就是BCL中有代码可以做到这一点.很多人都写过关于这样做的博客,但他们很少提及关于try/ finallyblocks 的事情,这是杀手.

我想知道的是:

• 是否有人在C#团队收到有关此主题的公开声明或直接电子邮件？
• 是否有任何现有的Microsoft Connect建议要求这样做？我听说过他们的谣言,但没有一个可能的关键词出现了什么.

更新:如上所述,我已经搜索过Microsoft Connect而没有找到任何内容.我也(不出所料)谷歌搜索.我只找到人们解释为什么他们需要这个功能,或者指出它在VB.NET中的优势,或者毫无结果地希望它将 …

我已经处理了一些实例,我会抛出/重新抛出异常,知道它周围的代码会捕获特定的异常.但是,有没有时间你想要抛出异常,知道它不会被抓住？

或者至少,没有捕获异常？

除非处理权利,否则例外会立即停止申请？所以我想我问你是否想故意让你的应用程序死掉？