我应该始终维护内部异常吗?

本文关键字：异常 内部 维护 我应该 | 更新日期: 2023-09-27 18:08:56

我有以下代码，我试图为异常提供更多信息:

int id = 5;
try
{
    var record = db.MyTable
                   .Where(x.Id == 5)
                   .Single();
    // more code here ...
}
catch (InvalidOperationException ex)
{
    string message = string.Format("Record doesn't exists for Id {0}", id);
    throw new InvalidOperationException(message, ex);
}

我是否应该维护内部异常，即使这个异常除了堆栈跟踪之外没有提供更多的相关信息?如上面的代码或;

我应该忽略异常，只抛出我需要的吗?throw new InvalidOperationException(message);

我应该始终维护内部异常吗?

您问的问题取决于正在执行的操作。如果我是你，我会尽可能保持内心的例外。从上面的例子中，您可能不需要Inner异常。

让我们看看这个场景

public class EmployeeDAO
{
    public void EmployeeInsert(Employee emp)
    {
        try
        {
           //Insert a Employee
        }
        catch (Exception ex)
        {
            string message = string.Format("Record doesn't exists for Id {0}", id);
            throw new Exception(message, ex);
        }
    }
}
在上面的

中，如果捕获并重新抛出如下所示的异常，则会丢失内部异常。内部异常将包含有用的信息，如连接问题或命令超时或任何类似的东西。

对于上面的事情使用预先存在的异常类型可能是丑陋的，因为没有一般的方法来区分Single抛出的InvalidOperationException，因为匹配记录的数量不完全是一个，从InvalidOperationException因为一些完全不同的原因被抛出。如果InvalidOperationException由于某些意外原因被抛出，而您只是简单地报告异常，就好像原因是意料之中的一样，那么故障排除可能会很困难。另一方面，如果你确实保留了异常，那么客户端将对它做什么就不太清楚了。

也许，即使基于异常消息做出决策通常是丑陋的，检查与底层异常相关的消息并在消息符合预期的情况下抑制内部异常的包含可能会有一些好处。对于Single方法的更改，这样的使用可能会使代码变得有些脆弱，但是在单个方法抛出带有预期消息的异常的情况下，以及由于意外原因抛出InvalidOperationException的情况下，都会提供更好的行为。这两个"胜利"可能足以克服这样一个事实，即更改Single可能会导致代码开始不必要地包括应该被视为预期场景的内部异常。

相关文章：