Внутренние маркеры ошибок

Question

Теоретически конечный пользователь никогда не должен видеть внутренние ошибки. Но на практике теория и практика различаются. Поэтому вопрос заключается в том, чтобы показать конечного пользователя. Теперь, для совершенно нетехнического пользователя, вы хотите показать как можно меньше («нажмите здесь, чтобы отправить отчет об ошибке« что-то вроде этого », но для более продвинутых пользователей они захотят узнать, есть ли работайте, если это было известно какое-то время и т. д. Поэтому вы хотите включить примерно информацию о том, что не так.

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

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

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

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

(Примечание 2: программа, о которой будет приложение командной строки работает на компьютере пользователя, но опять же, это только мое положение)

(Примечание 3:.. целевой язык D и I'm very willing для погружения в meta-programming. Ответы на другие языки более чем приветствуются!)

(примечание 4: Я явно хочу НЕ использовать фактические расположения кодов, а скорее некоторые символические имена для ошибок. Это связано с тем, что, если код изменяется практически любым способом, меняются коды.)

Answer 1

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

Answer 2

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

Для пользователя мы представляем страницу, в которой объясняется, что произошла неустранимая ошибка, и попросите включить имя файла в качестве ссылки, если они хотели бы сообщить об ошибке. Гораздо проще отладить всю эту информацию из контекста запроса о нарушении.

В PHP функция debug_backtrace() очень полезна для этого. Я уверен, что для вашей платформы есть эквивалент.

запомнить Также направить соответствующие заголовки HTTP: Возможно: HTTP/1.1 500 Internal Server Error

Учитывая разумный формат файла отчета об ошибке, это также можно анализировать ошибки, которые пользователи не сообщили.

Answer 3

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

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

Пример из программы Windows, использующей COM-сервер вне процессора. Если основная программа пытается создать объект из COM-сервера и завершается с сообщением об ошибке:

«ВНИМАНИЕ: Не удается Инстанцировать UtilityObject: Ошибка„Класс не Registered“в„CoCreateInstance“»

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

Чтобы связать некоторую контекстуальную информацию с утверждением, в моем коде на C++ я часто использую простую строку с именем метода или что-то еще, что дает понять, где произошла ошибка (я приношу свои извинения за ответ в язык вы не спрашивали о):

int someFunction() 
{ 
    static const std::string loc = "someFunction"; 
    : : 
    if(somethingWentWrong) 
    { 
    WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject: Error 'Class Not 
    Registered' in 'CoCreateInstance); 
    } 
} 

... который генерирует:

ПРЕДУПРЕЖДЕНИЕ [SomeFunction]: Невозможно Instantiate UtilityObject: Ошибка 'класс не зарегистрирован' в 'CoCreateInstance