систематизировать коды ошибок для веб-приложения в php?

Question

Я работаю над классным php-приложением. У меня есть несколько мест, где объекты взаимодействуют, и у меня есть определенные ситуации, когда я использую коды ошибок для связи с конечным пользователем - обычно, когда значения формы отсутствуют или недействительны. Это ситуации, когда исключения являются необоснованными (и я не уверен, что смогу избежать ситуаций с исключениями в любом случае).

В одном объекте у меня есть около 20 кодовых номеров, каждый из которых соответствует сообщению пользователя и сообщению администратора / разработчика, так что обе стороны знают, что происходит. Теперь, когда я работал над кодом несколько раз, я обнаружил, что трудно быстро выяснить, какие кодовые номера в серии я уже использовал, поэтому я случайно создал конфликтующие кодовые номера. Например, я только что сделал это сегодня с 12, 13, 14 и 15.

Как мне лучше организовать это, чтобы я не создавал конфликтующие коды ошибок? Должен ли я создать один одноэлементный класс errorCodes, который имеет основной список всех кодов ошибок для всех классов, систематизируя их по всему веб-приложению? Или каждый объект должен иметь свой собственный набор кодов ошибок, когда это уместно, и я просто сохраняю список в комментарии к объекту, чтобы использовать и обновлять его по мере продвижения?

---

Изменить: Так что мне нравятся предложения использовать константы или именованные константы в классе. Это дает мне единственное место, где я программно определяю и отслеживаю коды ошибок и их сообщения.

Следующий вопрос: какой интерфейс я предоставляю внешнему миру для кодов ошибок и сообщений этого класса? Должен ли я сделать что-то вроде triggerError(20) в классе, а затем предоставить открытый метод для возврата кода ошибки, строковой константы и сообщения, обращенного к пользователю и администратору?

Answer 1

Вы можете создать пару defines для создания именованных констант для всех ваших кодов ошибок:

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
}

Какой из них лучший ?

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

Answer 2

По крайней мере, можете ли вы увеличить кодовые номера до констант или членов класса?

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

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

Answer 3

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

Вы можете расширить базовый класс исключений, чтобы он соответствовал вашей проблеме с точки зрения сообщения об ошибке пользователя / разработчикаразделение.

Answer 4

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