返回 Null vs Exception vs Contract

Question

从数据库返回记录的可接受的处理方式有以下 3 种潜在结果：

1. Db 连接有效，找到用户并返回填充的用户对象
2. Db 连接有效，未找到用户，返回新用户对象
3. 数据库连接/查询失败...

我的主要目标是按合同设计：

class Scratch {
        public User getUser(int id) {
            try {
                // Prepare SQL Query
                PreparedStatement s = this.connection.prepareStatement(
                        "select * from get_user(?)"
                );

                // Provide SQL Parameters
                s.setInt(1, id);

                // Run our SQL
                ResultSet rs = s.executeQuery();
                rs.next();

                // Extract data into Entity
                User user = User.createFromDatabase(rs);
                rs.close();

                return user;

            } catch(Exception e) {
                e.printStackTrace();
            }

            return new User();
        }
}

在数据库连接或查询失败的情况下，我应该做什么不太明显，我有几个选择：

• 返回一个新的用户对象，因为我们的方法已经同意返回一个用户
  • 专业人士：坚持按合同设计
  • 缺点：这使它看起来用户不存在。
• 返回 null，因为它实际上并没有获得用户。
  • 专业人士：很明显，找不到用户
  • 缺点：需要空检查
• 抛出异常进一步向上链。
  • 专业版：明确说明未完成操作
  • 缺点：不会尝试纠正发生的问题

我倾向于处理异常，因为它避免了数十亿美元的错误，并且在正常情况下也保持了合同设计。

但是，我想知道是否存在任何明显的缺陷，或者这是否是一种熟悉的情况，并且有一个成熟的模式来解决它。

Answer 1

我会抛出异常并让用户知道连接失败。返回 NULL 是我永远不会做的事情，因为你不会知道问题出在哪里。

如果您没有与数据库的连接，我不知道您为什么会返回“新用户对象”。您将无法保存该用户。

我的选择是抛出异常

Answer 2

使用可选（请）。这明确表明无法在数据库中找到用户并避免 NullPointerException。

• 如果在数据库中找到用户，则可选（用户）
• 如果找不到用户则为空
• 如果出现错误，您有两种选择：
  • 通知客户端，以便它可以获取反馈并对失败做出反应。在这种情况下，抛出一个异常并在适当的层处理它。这应该是大多数应用程序的默认行为。
  • 向客户隐藏它，这种情况不太常见，但有时客户并不关心，或者您不想公布您的失败。在这种情况下，只需返回一个 Empty。