систематизация кодов ошибок для веб-приложения в php?
Я работаю над основанным на классах php веб-приложением. У меня есть некоторые места, где объекты взаимодействуют, и у меня есть определенные ситуации, где я использую коды ошибок для передачи конечному пользователю - обычно, когда значения формы отсутствуют или недопустимые. Это ситуации, где исключения являются неоправданными (и я не уверен, что мог избежать ситуаций за исключениями так или иначе).
В одном объекте у меня есть приблизительно 20 номеров кода, каждый из которых соответствуют стоящему с пользователем сообщению и сообщению admin/developer-facing, таким образом, обе стороны знают то, что продолжается. Теперь, когда я несколько раз работал по коду, я нахожу, что трудно быстро выяснить, какие номера кода в ряду я уже использовал, таким образом, я случайно создаю конфликтующие номера кода. Например, я просто сделал это сегодня с 12, 13, 14 и 15.
Как я могу лучше организовать это так, я не создаю конфликтующие коды ошибок? Я должен создать один singleton-класс, errorCodes, который имеет основной список всех кодов ошибок для всех классов, систематизируя их через целое веб-приложение? Или каждый объект должен иметь свой собственный набор кодов ошибок, в надлежащих случаях, и я просто сохраняю список в комментарии объекта, чтобы использовать и обновить это, поскольку я продвигаюсь?
Править: Таким образом, мне нравится, когда предложения используют константы или названные константы в классе. Это дает мне единственное место, где я программно определяю и отслеживаю коды ошибок и их сообщения.
Следующий вопрос: какой интерфейс я предоставляю внешнему миру для кодов ошибок и сообщений этого класса? Сделайте я делаю что-то как triggerError(20) в классе, и затем обеспечивают открытый метод возвратить код ошибки, строковую константу и пользователя - и стоящее с администратором сообщение?
4 ответа
Вы можете создать пару определений для создания именованных констант для всех ваших кодов ошибок:
define('ERROR_CODE_SQL_QUERY', 1);
define('ERROR_CODE_PAGE_NOT_FOUND', 2);
define('ERROR_CODE_NOT_ALLOWED', 3);
// and so on
А затем используйте константы в своем коде:
if ($errorCode == ERROR_CODE_SQL_QUERY) {
// deal with SQL errors
}
При этом нигде в вашем коде вы не будете использовать числовое значение: везде (кроме единственного файла, в который вы помещаете define s) , вы будете использовать коды.
Это означает:
- Меньший риск ошибок, так как все числовые значения задаются только в одном файле
- Меньший риск ошибок, так как вы будете использовать константы, имя которых указывает, что они означают
- И код, который легче читать.
Еще одна идея - создать класс для работы с ошибками:
class Error {
const CODE_SQL_QUERY = 1;
const CODE_PAGE_NOT_FOUND = 2;
const CODE_NOT_ALLOWED = 3;
// Add some methods here, if needed
}
А затем использовать что-то вроде этого:
if ($errorCode == Error::CODE_SQL_QUERY) {
// deal with SQL errors
}
Какой из них лучший ?
Вероятно, это вопрос личных предпочтений ... Если вам нужно добавить некоторые методы для работы с ошибками, использование класса может быть полезным. Иначе, определения - тоже отличное решение.
По крайней мере, вы можете поднять номера кода до констант или членов класса?
class MyErrorProneClass {
const TURNED_INTO_A_NEWT = 12;
...
public function dontBurnMe() {
// echo your error here using self::TURNED_INTO_A_NEWT
}
Таким образом, вы сможете управлять ошибками в том же месте, где вы их используете, вместо того, чтобы обслуживать большой центральный файл. В прошлом я пытался сделать нечто подобное, и это стало трудно поддерживать.
Генерация номеров ошибок программным путем может быть лучшим долгосрочным решением. Если бы вы могли использовать информацию о номере файла или строки (__FILE__ и __LINE__ соответственно), это бы помогло.
Надеюсь, это хотя бы продвинет в правильном направлении.
Спасибо, Джо
Edit:
Член класса будет иметь такой синтаксис:
class MyErrorProneClass {
protected static $turnedIntoANewt = 12;
...
public function dontBurnMe() {
// echo your error here using self::$turnedIntoANewt
}
Поскольку константы по умолчанию являются публичными, вы можете обращаться к ним из других классов напрямую, если хотите. Так, извне на ошибку можно было бы ссылаться как:
MyErrorProneClass::TURNED_INTO_A_NEWT
Для привязки к сообщениям, вы бы использовали связку (либо в базе данных, либо в каком-то файле локализации) от ID ошибки (и frontend/backend) к отображаемой строке. Такое использование ключей для сообщений не является оптимальным, но оно позволит вам изменять сообщения об ошибках без изменения кода.
Задумывались ли вы об использовании исключений ? Они могут быть хорошим выбором для вашей проблемы здесь, хотя добавление их в ваш проект сейчас, вероятно, потребует некоторой реструктуризации.
Вы можете расширить базовый класс исключений, чтобы он соответствовал вашей проблеме с точки зрения разделения сообщений об ошибках пользователя и разработчика.
Если вы еще не знаете, может быть идея использовать trigger_error () плюс обработчик ошибок, если вы хотите представить пользователю более удобное сообщение об ошибке.