Как далеко проверять ошибки и генерировать исключения?

Question

Я работаю над серверной частью своего веб-сайта, и мне интересно, как далеко я должен пройти проверку на наличие ошибок и соответственно генерировать исключения? Тестирование в смысле неправильного использования методов и функций.Не ошибки при правильном использовании.

Моя самая большая проблема - это раздувание кода и уродливание с помощью набора if / elses, проверок типов и других подобных тестов.

Если вы идетенастолько, чтобы рассмотреть каждый возможный способ, которым кто-то может использовать объект, перехватить все неправильное использование и выбросить исключения, чтобы понять разработчику, использующему его, что они сделали неправильно?

Или это лучшеподход, позволяющий коду естественным образом ломаться (очевидно, отлавливать и проверять вещи, которые будут иметь большое значение, но не для всех непредвиденных обстоятельств) и зависеть от того, кто использует код, чтобы прочитать доступную документацию и использовать ее соответственно?

Существуют ли общие рекомендации или рекомендации, которым необходимо следовать при решении таких вопросов?Я работаю в PHP, есть ли что-то конкретное для PHP, хотя эта проблема обычно распространяется на язык?

Спасибо за любую помощь по этому вопросу.

Answer 1

По крайней мере, ваше приложение не должно "ломаться": при обнаружении ошибки (будь то, потому что вы обнаружили, что проблема может возникнуть и ее удалось избежать, или потому, что проблема действительно произошла) , вы должны отобразить какое-нибудь приятное сообщение об ошибке, и, в конечном итоге, записать техническую информацию об ошибке.

По поводу вздутия кода: я бы не ставил слишком много тестов и все это в моем коде: это могло бы привести к чему-то сложному для понимания и поддержки - что важно!

Что я обычно пытаюсь сделать, это:

• Проверка на ошибки в предоставленных пользователем данных
  • Использование определенного класса, например, чтобы эти проверки не были в середине кода, который имеет дело с базой данных и бизнес-правилами.
  • Эти тесты относительно точны, чтобы генерировать полезные сообщения об ошибках для пользователя.
    • Например: " Вы не должны вводить более 20 символов "
    • Или " уже есть пользователь с таким адресом электронной почты "
  • В принципе, здесь важен пользователь.
• Когда пользовательские данные выглядят нормально, я работаю с ними.
  • И там, если произойдет какая-то ошибка, скорее всего, это будет техническая ошибка
  • Что должно быть зарегистрировано
  • И пользователю должно отображаться только « упс, произошла ошибка ».
  • Это означает, что здесь тесты не так точны: нам нужно только знать, работает ли он или нет - не обязательно в мельчайших деталях.

Конечно, в конце вы должны убедиться, что данные в БД верны, и что вы не сохраняете только половину данных.

Распространенным способом устранения технических ошибок является использование исключений; вот очень основная идея:

try {
    // Begin transaction to the DB

    // Some code that might fail and throw an Exception

    // Some other code that might fail and throw an Exception

    // Code here will not be executed if an Exception has been thrown

    // Commit DB transaction
} catch (Exception $e) {
    // Rollback transaction (cancels the queries that were sent to the DB)
    // Log technical informations to a file
    // Display a nice message
}

Самое замечательное в том, что он позволяет разместить весь код обработки ошибок в одном месте и поместить меньше тестирующего кода в середину важных вещей; то есть " пусть не получится, позже мы разберемся с проблемами "

Answer 2

Обычно я просто захожу настолько далеко, чтобы убедиться, что входные параметры метода и / или открытые члены заполнены и имеют правильный тип (string, int и т.д ...) Кроме этого я просто позволил этому сломаться естественно. (Если люди не собираются читать документацию, они заслуживают того, чтобы что-то сломалось.)

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