C# 在try块而不是catch块中引发异常？

我在我们的项目中继承了如下代码。它是类中的一个方法

protected override bool Load()
{
    DataAccess.SomeEntity record;

    try
    {
        record = _repository.Get(t => t.ID.Equals(ID));

        if (record == null)
        {
            throw new InvalidOperationException("failed to initialize the object.");
        }
        else
        {
            this.ID = record.ID;
            // this.OtherProperty = record.SomeProperty;
            // etc
        } 
    }
    catch (Exception)
    {
        throw;
    }

    return true;
}

如果我从UI层调用这个加载方法，我可能希望有一个try-catch块来捕获由于加载实例失败而导致的任何异常，例如invalidoOperationException，但是我觉得上面的代码不对

InvalidOperationException不会被catch语句吞没吗？catch语句还将捕获_repository.Get的潜在问题，以及记录有效时属性设置的潜在问题

我想我应该通过添加更多的try-catch语句来重新构造它，以分别处理Get操作和属性设置操作，或者添加更多的catch块来处理不同的异常，但我问了一位同事，他建议在这种情况下try-catch是不相关的，应该完全删除，让它像：

protected override bool Load()
{
    DataAccess.SomeEntity record;

    record = _repository.Get(t => t.ID.Equals(ID));

    if (record == null)
    {
        throw new InvalidOperationException("failed to initialize the object.");
    }
    else
    {
        this.ID = record.ID;
        // this.OtherProperty = record.SomeProperty;
        // etc
    } 

    return true;
}

---

我想听听第二种意见，我才刚刚开始对异常处理感兴趣，所以我想确保按照最佳实践以正确的方式进行处理。

如果您在调用方法中捕获异常（我认为），您应该只捕获您期望的异常。如果Load（）出现异常，则向调用方法抛出一个新异常，并提供有关该异常的更好信息。

太好了！你肯定是在正确的轨道上。以前的实现除了重新抛出不必要的异常之外什么也不做。您应该只处理您在业务层中预期的特定异常，否则让它们自然地从调用堆栈上升到UI层

作为最佳实践，只有当您想添加一些额外的调试信息时才重新抛出异常，在这种情况下，您需要在执行以下操作时定义自定义异常：

catch (Exception)
{
    throw;
}

您基本上没有处理异常。然而，这并不意味着你忽视了它。

throw

语句将异常传播到堆栈中。为了清晰可读的代码，您的最后一个示例要好得多。

异常将被

catch

语句捕获，但由于它有一个

throw

语句，它将抛出异常。这与你根本没有尝试/尝试的效果相同，因此你的同事建议将其忽略是正确的

---

如果您实际上没有以任何方式处理异常，那么添加异常处理代码没有多大意义。

我同意您的同事的看法，您应该只捕获您知道需要捕获的异常。我通常会省略任何try-catch块，除非我确切知道在特定情况下为什么需要它。这是因为如果您只是在所有内容周围放置try-catch块，那么您往往会在代码中隐藏真正的bug。关闭错误处理直到您完全需要它-在应用程序的最高点使用单个全局错误处理程序启动-如果这是asp.net，您可以挂接应用程序错误事件并在那里记录错误，但我的观点是不要添加try-catch块，除非您知道为什么添加它们并编写处理错误情况的代码不会捕获它们

---

享受吧

实际上，拥有此代码（在抛出

之前没有任何内容）的唯一原因是附加一个调试器（而不是全局调试|异常）。只捕获您知道需要捕获的异常。我通常会省略任何try-catch块，除非我确切知道在特定情况下为什么需要它。关闭错误处理直到您完全需要它-在应用程序的最高点使用单个全局错误处理程序启动-如果这是asp.net，您可以挂接应用程序错误事件并在那里记录错误，但我的观点是不要添加try-catch块，除非您知道为什么添加它们并编写处理错误情况的代码不会捕获它们。此外，如果您删除了try catchMake“您可以处理的异常”，则无需重新显示错误。您可以预期会有很多异常，但是，在代码中的这一点上，您的同事是正确的。两个版本都是一样的，那么为什么不减少代码呢？我建议在调试后保留throw-使用这段代码，您可以在throw上放置一个断点，然后检查异常（在即时窗口中使用
$exception
）。当你还不确定到底会有什么东西从那里冒出来时，这样做是有用的，正如其他海报所说，否则没有任何效果。