Question

我不确定在DAL类中处理异常的最佳位置。我有一些代码执行读取，并填充业务对象列表，如下面的伪代码：

public List<MyObject> GetMyObjects()
{          
  while (dataReader.Read()
  {
      try
      {
        //populate business object    
      }
      catch
      {
        //log exception?
      }
  }
}

我的问题是我不确定我的日志类是否应该在这个类中，但抛出异常是不可接受的，因为它会导致代码退出此方法。在这种情况下你们其他人做了什么？

注意：根据我们的业务规则，只需要记录无法正确加载的对象（这是由于我们在重构此代码的同时在数据库中解决的一些问题）。

Answer 1

异常处理的一般规则：如果您可以执行某些操作，只能捕获并禁止异常，如果可以对其执行某些操作，则没有理由记录下来:)）

如果这是你想做的事情，你可以抓住它来记录它，但如果这是唯一的原因，你必须在之后重新抛出它。

现在问问自己这个问题：我是否只关心DAL课程中的异常，或者我是否一般关心异常？

就个人而言，我不太关心在记录它时抛出异常。我做关心的是它完全被记录，所以我不是在特定类的异常处理中烘焙，而是以一般方式处理它。

异常处理是跨领域关注，应该这样对待。换句话说，为整个应用程序提供通用异常处理程序/记录器要好得多。 Here's an example我的意思。

Answer 2

通常，我会说DAL是处理异常的错误位置。我希望调用者能够正确处理它们。根据您的要求提出您的要求......我认为您没有太多选择。

我的建议是，如果你必须在DAL中处理异常，请稍微修改方法以允许调用者将Logging框架注入到方法中，这样你就不会关注什么是Logging工具了。正在使用：

public List<MyObject> GetMyObjects(ILogger logger)
{
    while(dataReader.Read())
    {
        try
        {
            // Do Stuff
        }
        catch(Exception ex)
        {
            logger.Log(ex.Message);
        }
    }
}

它会使代码看起来有点复杂，但是这种方法可以确保您的DAL没有与单个Logging Framework紧密耦合。

Answer 3

将记录调用放入DAL是很正常的。

只要您的日志记录代码实际上不使用DAL。

我建议使用Log4Net等日志框架。

Answer 4

我喜欢在DAL中登录的原因之一是，您有很多关于错误和上下文的有用数据。例如，您具有连接字符串，调用的存储过程的名称或运行的SQL的文本。您可以将所有这些信息添加到日志记录中。如果你让异常在代码层中冒泡，那么这些数据中的一部分将不再可用。

我仍然会重新抛出异常，以便相应的图层可以处理它或优雅地降级。

记录DAL类中的异常位置

4 个答案: