маркеры внутренних ошибок - PullRequest
Новая
       6

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

4 голосов
/ 25 ноября 2008

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

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

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

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

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

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

(Примечание 3: целевой язык D и Я очень хочу погрузиться в метапрограммирование . Ответы на другие языки приветствуются !)

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

Ответы [ 3 ]

2 голосов
/ 25 ноября 2008

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

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

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

Также не забудьте отправить соответствующие заголовки http: Возможно: HTTP / 1.1 500 Внутренняя ошибка сервера

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

1 голос
/ 26 ноября 2008

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

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

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

"ВНИМАНИЕ: Невозможно создать экземпляр UtilityObject: Error 'Class Not Зарегистрировано в "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

1 голос
/ 25 ноября 2008

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

...