Обработка ошибок: показать сообщение об ошибке или нет? - PullRequest
Новая
       19

Обработка ошибок: показать сообщение об ошибке или нет?

0 голосов
/ 22 июля 2010

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

  1. Показать сообщение об ошибке
  2. Не показывать сообщение об ошибке и вести себя так, как если бы ресурс был пуст (например, не заполнять компонент GUI)] *

Например, должен ли пользователь видеть пустой DataGrid, после чего он жалуетсяили должно быть сообщение об ошибке?Что лучше?

Ответы [ 4 ]

2 голосов
/ 22 июля 2010

Я не вижу это как / или.Кроме того, нам нужно учитывать всех «пользователей» системы.

Сначала рассмотрим пользовательский интерфейс.Давайте рассмотрим надуманный общий случай: вы заполняете пользовательский интерфейс, вызывая сервис, который, в свою очередь, использует несколько баз данных (например, «текущие данные» и «исторические данные»).

По крайней мере, есть следующие возможности:

  • Все это работает, данные извлекаются
  • Все работает, но, как это бывает, нет данных для этого конкретного запроса
  • Невозможно связаться со службой
  • Служба вызывается, но одна база данных не работает
  • Служба вызывается, но обе базы данных не работают

Затем также рассмотрите семантику вашего приложения.Может ли ваше приложение пройти в «ухудшенном» режиме, если все данные не могут быть восстановлены?Например, мы не можем запросить историю, но это не мешает нам создавать новый элемент.,

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

Мои общие правила:

  1. Первый сбой Сбор данных: какой компонент первым обнаружитошибка должна регистрировать это в некоторых деталях.Таким образом, обслуживание вверх, база данных вниз службы должны регистрировать проблему.Сервис отключен, пользовательский интерфейс должен регистрировать проблему.Этот журнал должен быть технической записью, предназначенной для ролей поддержки.
  2. Интерфейсы должны быть терпимыми: если это вообще возможно, работать в ухудшенном режиме.Поэтому, если служба не работает, но (например) локальная работа возможна, поднимите пустой экран и продолжайте.НО ...
  3. Всегда указывают на проблему: случаи "нет данных для этого запроса" и "базы данных недоступны" могут привести к пустому экрану.Пользователь должен знать состояние дисплея, показывает ли он полную информацию, частичную информацию (например, из-за того, что одна БД не работает) или информация недоступна (например, сервис или обе базы данных отключены).Так что есть поле «Статус» где-то на экране.Предоставление сообщений, таких как

Historica. Данные, недоступные в настоящее время

или

При получении информации возникают проблемы, если они не исчезли, пожалуйста,обратитесь в службу поддержки ...

1 голос
/ 22 июля 2010

Есть некоторые подводные камни для каждой из опций

Отображение сообщения об ошибке

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

Однако иногда это сообщение об ошибке становится очень уродливым (стеки вызовов и т. Д. - помните ASP.NET?), И оно становитсянастолько большой, что клиентам становится трудно копировать детали.

Не показывать сообщение об ошибке и вести себя так, как будто ничего не произошло =)

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

Моя позиция

Получите лучшее из обоих миров.На самом деле большинство современных приложений имеют очень хороший процесс обработки ошибок.Я возьму пример Mozilla Firefox 3.

  1. Произошла смертельная ошибка и произошел сбой Firefox
  2. Ошибка фиксируется и сохраняется в файле в виде отчета об ошибке
  3. Появляется сообщение об ошибке приложения с извинениями для пользователя
  4. Спросите пользователя, хочет ли пользователь отправить отчет об ошибке в группу разработчиков программного обеспечения
  5. Затем спросите пользователя, хотите ли вы перезапуститьapplication

Или, если ошибка является предупреждением или имеет меньшую серьезность:
Покажите простой код ошибки и сообщите пользователю, что произошла ошибка с этим действием.Что-то вроде: «Ошибка 123 в RequestSalary () Строка 2»

0 голосов
/ 22 июля 2010

IMO, вы должны показать сообщение (хотя и удобное для пользователя, а не что-то вроде «java.io.IOException: Соединение истекло».) У вас может быть окно с сообщением о том, что произошла ошибка при получении данных и предоставьте полезные советы, например: попробуйте через некоторое время, проверьте сетевой кабель и т. д. Также разрешите пользователю сообщать вам об этой ошибке (встроенной в приложение системы отчетов об ошибках), которая отправит вам фактическую ошибку и трассировку стека.

0 голосов
/ 22 июля 2010

Практика, которую я обычно использую:

  1. Если ошибка не произошла из-за ошибки пользователя, вам следует попытаться спокойно обработать ошибку.
  2. Если ошибка произошла из-за какой-либо внешней проблемы (например, отсутствия подключения к Интернету), вы должны предупредить пользователя.
...