Сколько информации об ошибке должно быть показано пользователю?

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

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

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

что показать пользователю. Должно ли это быть скрыто от пользователя?

Вы показываете пользователю, что является для него действенным.

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

Или мы все равно должны это показать? Или мы должны показать общее сообщение?

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

мы должны показать одно из нескольких сообщений, основанных на том, что является основным исключением?

Лучшая стратегия заключается в следующем:

• Интерпретировать ошибку в текст, который имеет смысл для пользователя.
  • Частично это "что пользователь может сделать по-другому?"
  • Если они не могут сделать что-то другое, скажите что-то вроде «произошла неожиданная ошибка».
• Добавьте «необязательное» подробное описание ошибки
• Разрешить пользователям отправлять отчет об ошибках (или делать это автоматически, в зависимости от базы пользователей)

пример

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

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

Это зависит от того, кто пользователь, и что они могут делать с информацией.

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

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

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

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

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

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

Это общая тема:

Как вы можете помочь неосведомленному / неграмотному компьютеру в то же время показывать информацию, которую могут использовать более продвинутые пользователи, такие как программисты, разработчики, тестировщики и т. Д.

Я думаю, что ответ вы оба!

Порядок важен, хотя, и я рекомендую вам:

• Что произошло.
• что делать сейчас
• Технические подробности

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

То, что вы хотите показать, зависит от того, насколько вам стыдно за то, что вы все испортили.

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

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

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

Хотя я мало что знаю об авиации, скажем, мой рейс задерживается или отменяется, и единственное, что сотрудники говорят мне: «У нас произошла непредвиденная ошибка. Пожалуйста, подождите 3 часа для следующего рейса». По крайней мере, вы найдете меня немного более рассерженным клиентом в этих случаях, потому что, хотя это и не влияет на мой образ действий в любом случае, я просто хочу узнать немного больше о том, почему я являюсь неудобно, как платящий клиент.

Если они просто сказали: «У нас непростая погода» или «У нас произошла неотложная медицинская помощь во время нашего предыдущего полета», или неисправность оборудования или что-то еще, этого достаточно для меня, чтобы сочувствовать гораздо большему, чем «неожиданная ошибка» и быть немного более довольным сидеть без дела и ждать 3 часа следующего рейса. На самом деле, я бы даже предпочел, чтобы какой-нибудь техноаббл, который у меня над головой звучал, как «неожиданная ошибка» вроде: «Хорошо, слова, исходящие из твоего рта, попадают мне в ухо, но не доходят до центрального процессора. Но теперь я понимаю, что есть какая-то и я пойду, возьму немного кофе и сижу там! Надеюсь, вы, ребята, разберетесь с этим вопросом с этой штукой! "

И часто с точки зрения обработки исключений, я думаю, что вам обычно достаточно такой базовой информации о том, что произошло на catchсайте, даже если вы хотите скрыть более технические детали исключения, например:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

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

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