Использовать коды ошибок или не использовать коды ошибок

Question

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

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

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

Answer 1

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

Answer 2

В зависимости от языка кодирования могут быть культурные различия?

Например, в Java числовые коды ошибок используются не очень ...

---

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

---

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

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

---

Чтобы решить ваши две проблемы:

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

Answer 3

Вы можете включить код ошибки в исключение, тем самым получая лучшее от обоих.

Одной из частых причин ошибок с кодами ошибок возврата в старом стиле была неспособность проверить код ошибки перед продолжением следующего кода. Исключение нельзя неявно игнорировать. Устранение источника ошибки - это хорошо.

Код ошибки позволяет:

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

Несколько рекомендаций, которые я нашел полезными:

• Только архитектурные слои пользовательского интерфейса создают и локализуют сообщения для пользователя.
• Когда уровни, не связанные с пользовательским интерфейсом, сообщают об ошибках через исключения, они могут дополнительно содержать коды ошибок и дополнительные поля, полезные для пользовательского интерфейса при создании сообщения.
• В Java, когда коды ошибок определены в уровне Enum пользовательского интерфейса, строки формата сообщения об ошибке могут быть доступны через сами перечислители. Они могут содержать символы для дополнительных данных, переносимых в ошибке.
• В Java включите индекс аргумента в спецификаторы формата в строках формата исходного языка, чтобы переводчики могли перемещать динамические данные в локализованных сообщениях.