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

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

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: ясно дает понять, что операция не выполнена.
  • Против: не пытается исправить проблемы там, где они возникают.

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

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