【问题标题】:Exception treated as user-unhandled even though it's handled异常被视为用户未处理,即使它已被处理
【发布时间】:2012-04-02 12:48:43
【问题描述】:

短版:

为什么 Visual Studio 告诉我代码引发了用户未处理的异常,即使我捕获了异常?

加长版:

我正在使用实体框架和Microsoft's transient fault handling framework

我的实体框架类是部分的,我有自己的方法 SaveChangesWithRetries 执行重试逻辑:

public partial class EfContext
{
    public virtual void SaveChangesWithRetries()
    {
       var retryPolicy = RetryPolicyFactory.GetDefaultSqlCommandRetryPolicy();
       retryPolicy.ExecuteAction(() =>
                       {
                          SaveChanges();
                       });
    }
 }

我使用这个函数的代码可能如下所示:

try
{
    context.SaveChangesWithRetries();
}
catch (OptimisticConcurrencyException)
{
    continue;
}

即使我捕获了 OptimisticConcurrencyException 异常,Visual Studio 也会停止调试器并告诉我对 ExecuteAction() 的调用引发了用户未处理的异常。发生这种情况时,调试器会在 EfContext 类中停止。如果我按 F10,调试器将移动到 catch (OptimisticConcurrencyException)。

我不明白为什么 VS2010 告诉我有一个用户未处理的异常,即使我有一个捕获并且即使我的捕获捕获了异常。

【问题讨论】:

  • continue 在你的catch 中做什么?

标签: visual-studio-2010 exception-handling unhandled-exception


【解决方案1】:

找出造成这种情况的原因。

  1. 我们的代码启动了一个 try/catch 子句
  2. 我们的代码称为瞬态故障处理框架 (TFHF)
  3. TFHF 调用了我们的代码(通过 lambda 表达式9
  4. 我们的代码抛出异常

由于 TFHF 是在 release 中内置的,.NET Framework 无法理解我们自己的代码在步骤 0 中捕获了异常,该异常在步骤 3 中被抛出。

【讨论】:

    【解决方案2】:

    我有一个类似的问题,我需要一个异常通过一些 .NET 代码传播,以便我可以在另一端捕获它。我发现 Debug>Exceptions 对话框允许您选择希望 VS 中断的异常类型。对于每种 Exception 类型,您可以检查它是否应该在抛出异常时或仅在未处理时才中断。因此,我所做的是选择一个深奥的异常类型,默认情况下未选中“用户未处理”的“用户未处理”,并将我想用该类型的异常传播的异常包装起来。具体来说,我选择了 AppDomainUnloadedException,因为它在 System.dll 程序集中,因此我的项目已经引用了它。

    这是我的代码,它包装了我需要传播的 IOException:

    public override int Read(byte[] buffer, int offset, int count)
    {
        try { return innerStream.Read(buffer, offset, count); }
        catch (IOException ex) { throw new AppDomainUnloadedException("Exception from innerStream: " + ex.Message, ex); }
    }
    

    这是我的代码,我在它需要传播的 .NET 代码的另一端捕获它:

    try { bytesRead = sslStream.Read(buffer, offset, count); }
    catch (Exception ex) { /* ex handled here. */ }
    

    问题解决了。 VS 在引发 IOException 时不再中断 innerStream.Read。

    【讨论】:

    • 这似乎是一个丑陋的解决方案,迟早会引起混乱。 :)
    • 这肯定是一个 hack,但它确实有效,这总比没有好。至于未来的混乱,这就是我们有 cmets 的原因。 :)
    猜你喜欢
    • 2015-11-03
    • 1970-01-01
    • 1970-01-01
    • 2015-06-01
    • 1970-01-01
    • 1970-01-01
    • 2013-10-11
    • 2021-06-19
    • 1970-01-01
    相关资源
    最近更新 更多