当来自 db 的数据错误时，是否应该引发异常

本文关键字：是否 异常 db 错误 数据 | 更新日期: 2023-09-27 18:31:20

在此特定应用程序中，没有单独的数据层，数据访问代码位于实体本身中。例如，考虑一个 Customer 实体，然后在定义成员和属性的 Customer.cs 文件中，您有加载 Customer 对象的方法，如下所示

public bool TryLoad(int customerID, out Customer customer)
{
    bool success = false
    try
    {
        //code which calls the db and fills a SqlDataReader
        ReadDataFromSqlDataReader(reader);
        success = true;
    }
    catch(Exception ex)  
    {
      LogError();
      success = false;
    }
    return success;
}

现在，在 ReadDataFromSqlDataReader（reader） 中，tryparse 用于将数据从读取器加载到对象中。 

public void ReadDataFromSqlDataReader(reader)
{
   int.TryParse(reader["CustomerID"].ToString(), out this.CustomerID);
   PhoneNumber.TryParse(reader["PhoneNumber"].ToString(), out this.PhoneNumber);
   ... similar TryParse code for all the other fields..
}

使用 TryParse 从读取器读取所有属性是否是一种好的做法？一位开发人员告诉我，它是这样完成的，因为 TryParse 的性能比 int 更好。解析。但是，当您从数据库读取的值不符合您的代码预期时，您是否不希望引发异常？我的意思是，在这种情况下，如果数据库中的电话号码错误，那么也许根本不应该初始化该对象，而不是加载带有空电话号码的对象？

当来自 db 的数据错误时，是否应该引发异常

是的，遵循快速失败原则，您希望在返回无法转换为预期类型的值时引发异常。

如果其中一个操作失败，而您继续前进，就好像什么都没发生一样，您可能会遇到难以捕获且难以查明的奇怪错误：对象在本应更新现有行时被添加到数据库中，数据神秘地消失，狗和猫生活在一起......你明白了。

另一方面，如果您立即抛出异常，您确切地知道问题所在，并且可以在它变得更糟之前捕获并修复它。

TryParse在失败的情况下会比Parse更快地工作，因为它不必抛出异常（这可能很昂贵），但如果你假设事情会成功（这段代码是通过不使用解析结果来做的），你应该使用 Parse 获得等效的性能。

在插入和/或更新数据时，您正在执行哪种验证？

只要您在此处应用某种形式的验证，我个人就不会验证来自数据库的数据，因为您应该确信您只输入了有效数据。

将数据插入数据库时执行有效验证。这不是一个好的设计，可以将不良数据输入到数据库中。如果数据库包含错误的电话号码，则应要求用户再次输入电话号码（如果这是强制性的），如果电话号码不是那么重要，则可以在出现错误数据的情况下将电话号码初始化为空。

我不会为此使用TryParse。如果我的数据库里面有垃圾，我希望解决这个问题。如果数据在解析方面不明确（例如，将 int 或 double 作为字符串放入 Varchar）我想整理我的模式，TryParse 作为类型检测将是一个快速而简单的黑客。

如果你要处理它，嗯，是的，你应该抛出一个异常。但是，如果您不关心异常，并且要过滤正确的数据并使用它（在本例中为非零），则可以跳过。

As，TryParse返回布尔值。因此，我可以根据Boolean值ByPass/Continue Upcoming Logic/Any Database请求。我不会让例外发生在这样的风景中。为此，我将进行日志记录等。

解析

  1. 引发异常。
  2. 如果您确定该值有效，请使用它

TryParse

  1. 返回一个布尔值，指示它是否成功
  2. 它只是在内部尝试/捕获为什么无异常地实现，以便快速
  3. 在值可能无效的情况下使用它
相关文章：