Простая проверка ошибок в цепочке функций класса PHP? - PullRequest
1 голос
/ 04 июня 2011

Я нашел некоторое ограниченное использование в цепочечных функциях класса, скажем $class->setUser('foo')->getInfo() (плохой пример), хотя у меня возникают проблемы с пониманием того, как обрабатывать любые ошибки, возникающие в результате одного из вызовов в цепочке.

Если, например, setUser() пришел с ошибкой и вернул false, он не вернул бы $this и не позволил бы вызвать другую функцию, таким образом отображая ошибку.

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

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

Ответы [ 2 ]

3 голосов
/ 04 июня 2011

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

Вот пример того, как это может работать:

try
{
    $class->setUser('foo')->getInfo();
}
catch(UnknownUser $ex)
{
    // setUser failed
}
catch(CannotFetchInfo $ex)
{
    // getInfo failed
}
1 голос
/ 04 июня 2011

Как и для любых цепей: если один элемент разорван, вся цепочка разорвана.

Таким образом, если вы объединяете объекты в цепочку, с одной стороны, это может быть очень доступно, с другой стороны, если что-то происходит из-за ошибок (например, удаленных подключений, файлов и т. Д.), Цепочка становится неудобной.

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

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

Преимущество создания исключения состоит в следующем: вам не нужно уничтожать синтаксис, который делает цепочку доступной.

Допустим, вы допустили ошибку в своем коде. Лучше бросить исключение, так как вам все равно нужно это исправить.

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

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

Итак,

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

Независимо от того, насколько хорошо выполнено построение цепочки, наступает момент, когда он больше не имеет смысла (следует добавить «как со всем»;)). Я бы не сказал, что я настоящий фанат цепочек, но даже будучи не фанатом, я время от времени использую этот принцип в своем собственном коде. Он может создавать простой для написания код, поэтому используйте исключения для обработки ошибок, я не столкнулся с какими-либо «реальными» (tm) проблемами с ним. Это гораздо лучше, чем разорвать вашу цепь с помощью ложного или какого-то подобного дерьма.

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

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

...