Как при разработке проекта среднего размера вы можете идентифицировать, создавать и поддерживать коды ошибок?
Я за свою жизнь не могу придумать простой и чистый способ сделать это. Некоторые из моих идей преобразовывают имена классов и имен методов в целочисленную строку, но это слишком длинный способ отображать пользователю поверх факта, что имена методов и имена классов могут изменяться (надеюсь, нет!). Другие просто используют возрастающую систему журналов (т.е. когда я создаю новое сообщение об ошибке, просто добавьте 1 к последнему идентификатору сообщения об ошибке). Но это просто неорганизованно.
Чтобы быть более конкретным, я говорю о коде ошибки, таком как:
Error 401 Unauthorized.
error-messages
ahodder
источник
источник
Ответы:
Нет.
Коды ошибок являются анахронизмом, они берут свое начало в те старые времена, когда вывод был действительно сложным и дорогим, и единственный способ сообщить об ошибке, возможно, был через несколько индикаторов на передней панели:
В наши дни мы имеем зрелую обработку исключений, встроенную практически во все основные языки. Используй это. Предоставьте пользователю информацию, с которой он может работать; не беспокойте их техническим бла-бла, а скорее расскажите им, что пошло не так и что они могут с этим сделать. Для регистрации просто дайте своим исключительным именам имена и зарегистрируйте имя. Легче запомнить, а также легче найти с помощью grep или аналогичных инструментов поиска.
Исключением, конечно, является ситуация, когда вы программируете для ситуаций, когда вывод по-прежнему труден и дорог, например, для встроенных систем или сетевых протоколов. HTTP по-прежнему использует числовые коды ответов, потому что их чрезвычайно легко эффективно анализировать - в некоторых ситуациях чтение только первой цифры уже может сказать вам достаточно, и вы можете отказаться от остальной части пакета.
источник
Вы должны проверить, как коды ошибок / состояний организованы в общих протоколах, таких как HTTP . Они резервируют различные диапазоны для различных типов состояний / ошибок. Это облегчает как пользователям идентификацию неизвестного кода состояния, так и разработчикам, чтобы назначить код для нового типа ошибки, которая не была обработана ранее.
источник
Извините, зачем вообще использовать коды ошибок?
Перехватите исключение, зарегистрируйте его и предложите отправить отчет, если программа не может восстановиться .
(Предполагая, что ваш язык поддерживает исключения.)
Единственная релевантная информация, которая может помочь вам исправить ошибку - это трассировка стека, которую вы не получите с кодом ошибки. (Я также предполагаю, что вы хотите использовать коды ошибок для отчетов об ошибках, а не бросать их в лицо пользователя.)
источник
Я собираюсь принять процедурный контекст (С). Если у вас есть объекты, объект ошибки обычно лучше, независимо от того, является ли это исключением или нет.
Вы должны использовать коды ошибок, локальные для каждого модуля. Для библиотеки у вас может быть специальный заголовок со списком кодов ошибок, с номерами 1, 2 и т. Д. (Или -1, -2, если вы предпочитаете). Обязательно всегда возвращайте один из этих кодов, например, переводите
errno
в свои собственные коды. Если у вас есть несколько уровней модулей, переводите на каждом шаге (или задайте диапазон для более глубокой ошибки, например, значения 1001 - 1050 взяты из этого другого модуля).Также важно, чтобы вы предоставили средства для перевода кода в строку. Вы никогда не должны сообщать только код, который только приводит к разочарованию. На самом деле практически любой код в вашем приложении должен иметь функцию перевода строки. Например, libc обычно имеет
strerror
иstrsignal
, но, к сожалению, не хватаетstrwaitstatus
.источник