1) На продакшн сервере замечания стоит игнорировать, если они не влияют на работу программы и от них нельзя избавиться, изменив код на правильный. Это, конечно, не отменяет рекомендации избавляться от любых ошибок и предупреждений, выдаваемых программой, на самом детальном уровне показа ошибок.
2) Некоторые исключения, действительно, можно и нужно обрабатывать внутри библиотеки. Наружу должны выходить только те исключения, которые исчерпывают все разумные возможности библиотеки по их обработке. Если вы будете отправлять во внешнюю программу все возникающие исключения, даже из самого малозначимого метода, то тем самым вы усложните работу с библиотекой и уменьшите сокрытие информации, производимое библиотекой. В этом смысле я полностью согласен с MikhailEdoshin.
3) Коды возврата ошибок в PHP — это всего лишь наследие C, на котором написан PHP и который не имеет встроенного механизма исключений. В С++ с этим даже есть проблемы — некоторые библиотеки уже кидают исключения, а другие — возвращают коды ошибок и иногда получается каша при разработке. Я считаю, что для упрощения работы с подобными библиотеками следует использовать один из способов — либо исключения, либо коды ошибок. Поскольку PHP поддерживает исключения, то следует использовать именно их. Что-то я не видел, чтобы, например, Yii возвращал бы код ошибки вместо выбрасывания исключения.
4) Что касается использования функций set_error_handler \ set_exception_handler — ничто не мешает вам выбросить наружу ту же самую ошибку или исключение с помощью trigger_error \ throw.
Я не путаю ошибки и исключения, я ведь так и написал: "1) Любые ошибки и предупреждения PHP транслировать в исключения с помощью set_error_handler". Я согласен, что лучше выдать страницу ошибки, чем неверные данные, но в моем случае речь идет не о приложении, а о наборе классов, который планируется применять в других приложениях. Не имеет право этот набор классов показывать какие-либо страницы, это ведь не веб-фреймворк. Он может либо кинуть исключение и обработать его как-то внутри себя, либо кинуть его наружу и пусть его обрабатывает само приложение. Если транслировать замечания и ошибки в исключения, то, например, замечания на продакшн сервере все-таки стоит игнорировать, а вот при разработке — нет. Именно для этого и предполагается сделать некоторые исключения игнорируемыми.
Ну как же! Исключения кидают большинство фреймворков. Причем часто для исключений внутри фреймворка определяется свой обработчик по-умолчанию, который просто выводит страницу со Stack Trace.
Примерно это я и имел в виду. Т.е. в итоге ассерты используются независимо от модульного тестирования как самостоятельный инструмент? Я просто мало где их видел конкретно в PHP.
Да, действительно, про это я забыл. Но тут дело в представлении кодов ошибок: они так выбраны, чтобы можно было применять подобные операции. А еще хотя бы один пример? =)
Я этим как раз сейчас и занимаюсь. Просто есть вопросы, которые в опенсурсе не очень обсуждаются. Работая там скорее можно понять как сделать, какие использовать программы, какие есть наиболее совершенные технологии и так далее. Работа с OS не дает понимания почему сделано именно так. Например, я понял, что не очень хорошо разбираюсь в структурах данных. Возможно, в веб-программировании мне не часто понадобятся такие понятия как стек, куча, список, разные виды деревьев, однако, само знание о таких структурах может наводить на нестандартные алгоритмы, решающие поставленную задачу оригинально и эффективно. Поэтому и ищу такие возможности.
