Возврат Нуль против Исключения против Контракта

Question

Что считается приемлемым способом возврата записи из БД со следующими 3 потенциальными результатами:

1. Соединение в БД работает, находит пользователя и возвращает заполненный пользовательский объект
2. Соединение с БД работает, пользователь не находит, возвращает новый объект пользователя
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();
        }
}

В случае сбоя соединения с БД или запроса немного менее очевидно, что мне следует делать, у меня есть несколько вариантов:

• Возвращает новый пользовательский объект , потому что наш метод согласился вернуть пользователя
  • Pro: Это придерживается проектирования по контрактам
  • Con: Это делает его похожим на пользователяне существует.
• Возврат null , поскольку он фактически не получил пользователя.
  • Pro: Совершенно очевидно, что пользователь не был найден
  • Con: Требуется нулевая проверка
• Бросить исключение дальше вверх по цепочке.
  • Pro: четко указывает на то, что операция не была достигнута
  • Con: не пытается исправить проблемы, в которых они произошли

Я склоняюсь к обработке исключений, поскольку это позволяет избежать ошибки в миллиард долларов, а также поддерживает проектирование по контракту в обычных ситуациях.

Однако я хотел бы знать, есть ли какие-либо очевидные подводные камни или этознакомая ситуация с устоявшимся шаблоном для ее решения.

Answer 1

Используйте опционально (пожалуйста).Это делает явным, что пользователь не может быть найден в базе данных, и избегает исключения NullPointerException.

• Необязательно (пользователь), если пользователь найден в базе данных
• Пусто, если пользователь не найден
• При наличии ошибки у вас есть два варианта:
  • Уведомить клиента, чтобы он мог получить обратную связь и отреагировать на эту ошибку.В этом случае выведите исключение и обработайте его в соответствующем слое.Это должно быть поведение по умолчанию для большинства приложений.
  • Скрыть это для клиента, это не так часто, но иногда клиенту все равно, или вы не хотите публиковать свои ошибки,В этом случае просто верните Empty.

Answer 2

Я бы выдал исключение и сообщил бы пользователю, что соединение не установлено.Возврат NULL - это то, чего я бы никогда не сделал, потому что вы не знаете, в чем проблема

Я не знаю, почему вы бы вернули «Новый пользовательский объект», если у вас нет подключения к базе данных.Вы не сможете сохранить пользователя.

Мой выбор будет выбрасывать исключение