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

Question

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

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

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

Answer 1

Возможно, существуют культурные различия, согласно вашему языку кодирования?

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

---

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

---

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

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

---

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

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

Answer 2

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

Answer 3

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

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

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

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

Несколько советов я нашел полезный:

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