Удобство использования на практике

Когда возникают сбои

Др. Чарльз Крейтцберг и Эмброз Литтл

Загружаемый файл с кодом доступен в коллекции кода MSDN
Обзор кода в интерактивном режиме

Cодержание

Проблема удобства использования
Значимость сообщений об ошибках
Важные вопросы, которые следует поставить на этапе проектирования
Форматирование сообщений об ошибках
Приемы программирования
Согласованная обработка
Грамотно составленное сообщение об ошибке
Рабочие среды
Настройка исключений (с использованием библиотеки Enterprise Library)

kreitzberg.gif

Чарльз Крейтцберг (Charles Kreitzberg)

ПРОБЛЕМА УДОБСТВА ИСПОЛЬЗОВАНИЯ

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

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

  1. В нем не указано, какая программа создала это сообщение об ошибке.
  2. В сообщении не поясняется, почему программа завершается.
  3. Сообщение имеет очень общий характер. В нем говорится о «сведениях о безопасности» без какого бы то ни было намека на характер этих сведений.
  4. В сообщении не указывается, насколько серьезна неполадка и нет ли опасности для компьютера пользователя.
  5. Пользователь не имеет никакого представления о том, как устранить неполадку или получить дополнительную справочную информацию. Всё, что он может сделать, это нажать кнопку OK (очевидно, что на деле все не так уж ОК).

fig01.gif

Рис. 1 Ого! Завершение программы грозит неприятностями

fig02.gif

Рис. 2 Гм-м, а что, если меня не будет дома, когда Windows обратится ко мне?

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

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

  • Сообщает о возникновении неполадки.
  • Дает объяснение причины.
  • Предоставляет решение, чтобы пользователи могли исправить неполадку.

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

  • Важность. Сообщение представляет неполадку, имеющую значение для пользователей.
  • Наличие вариантов действий. Получив сообщение, пользователи должны либо выполнить какое-то действие, либо изменить свое поведение.
  • Ориентированность на пользователя. Сообщение описывает неполадку в терминах действий пользователя или целей, а не в терминах того, что оказалось коду не под силу.
  • Краткость. Сообщение должно быть настолько кратким, насколько это возможно, но ни в коем случае не короче.
  • Четкость. Сообщение должно быть сформулировано простым языком, чтобы пользователь, к которому оно обращено, без труда понял характер неполадки и предлагаемое решение.
  • Конкретность. Сообщение описывает неполадку с использованием соответствующего языка, предоставляя конкретные имена, местоположения и значения вовлеченных в неполадку объектов.
  • Учтивость. Не следует порицать пользователей или вызывать у них чувство собственного недомыслия.
  • Редкость. Не следует отображать сообщения слишком часто. Частое отображение сообщение об ошибках является признаком плохого проекта.

Сообщение на рис. 2 не соответствует большей части этих критериев.

Значимость сообщений об ошибках

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

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

Важные вопросы, которые следует поставить на этапе проектирования

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

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

О каких типах исключений вы собираетесь сообщать? Как вы предполагаете их представлять?

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

Каким образом предполагается возобновить работу пользователя? Простое уведомление пользователя о возникновении неполадки без предложения набора действий для устранения неполадки неизменно приводит к отрицательным последствиям для условий работы пользователя.

Требуется ли ведение журнала и создание уведомлений о возникновении исключений? Если да, вам, возможно, придется обдумать, как организовать для пользователей и сотрудников отделов ИТ просмотр, поиск, сортировку, фильтрацию и сопровождение журналов, и как форматировать содержимое уведомлений. Журналы и уведомления должны быть в высшей степени удобными для использования.

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

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

Эти вопросы следует рассмотреть на раннем этапе проектирования, не откладывая их на конец.

Форматирование сообщений об ошибках

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

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

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

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

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

Предоставление подробных сведений и рекомендаций Для исключений высокого уровня серьезности, например «HTML, ошибка -500 - Внутренняя ошибка сервера», постарайтесь, если есть возможность, предоставить более подробные сведения и соответствующие рекомендации. Объясните, какие действия может предпринять пользователь для устранения ошибки, и убедитесь, что варианты действия и последствия четко сформулированы. Если возможно, предоставьте ссылку на более подробные сведения, которые облегчат пользователю принятие подходящего решения. Если существует единственный вариант, состоящий в предложении обратиться в службу технической поддержки, убедитесь в том, что контактная информация является точной и легко обновляется.

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

little.gif

Эмброз Литл (Ambrose Little)

ПРИЕМЫ ПРОГРАММИРОВАНИЯ

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

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

Согласованная обработка

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

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

Грамотно составленное сообщение об ошибке

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

fig03.gif

Рис. 3 Формат сообщения о простой ошибке .

fig04.gif

Рис. 4 Сообщение для более сложной ошибки .

Источником полезных сведений по обработке исключений может служить статья библиотеки MSDN «.NET Framework Developer's Guide: Design Guidelines for Exceptions» (Руководство для разработчиков .NET Framework. Рекомендации по проектированию обработки исключений). Посетив библиотеку MSDN, загляните заодно в статью «Exception Handling Application Block» (Блок приложения для обработки исключений). Он позволяет создать обертку для исключения, поместив его внутрь исключения, которое вы самостоятельно создаете и сопровождаете дополнительными сведениями. Этот прием можно использовать для добавления дополнительных сведений, охватывающих контекст, в котором возникло исключение. Такие сведения можно использовать для создания сообщений об ошибках, в большей степени ориентированных на пользователя.

Если дело касается безопасности, и вам требуется избежать передачи технических сведений, такое исключение можно заменить другим, в большей степени ориентированным на пользователя, вместо того, чтобы обертывать его в собственное исключение. Наконец, блок обработки исключений (Exception Handling Block) можно использовать для регистрации ошибки и уведомления соответствующих заинтересованных лиц посредством электронной почты, средств WMI (Windows Management Instrumentation — инструментарий управления Windows) или другого специального механизма.

Если вам требуются облегченные средства регистрации и создания отчетов об ошибках для ASP.NET, воспользуйтесь материалом Error Logging Modules and Handlers (ELMAH) (Набор модулей и обработчиков для ведения журнала ошибок). Там предлагается способ ведения журналов, несколько вариантов хранения журналов, возможность просматривать журналы на веб-странице, передача по электронной почте и уведомления по каналу RSS. Можно также создать обработчик исключений ELMAH для EntLib, например, доступный бесплатно на веб-сайте dotNetTemplar. Таким образом вы получаете инфраструктуру, обеспечиваемую EntLib, и службы формирования отчетов, которые вместе с ней предоставляет ELMAH.

Если вы занимаетесь созданием приложений для среды Windows XP или Windows Vista, вам имеет смысл обратить внимание на службу отчетов об ошибках Windows (Windows Error Reporting Service, Dr. Watson). Когда пользователь отправляет данные о сбое, служба отчетов об ошибках Windows выполняет проверку, чтобы выяснить, имеется ли связанное с ним сообщение пользователя, и представляет сообщение на момент сбоя.

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

Теперь давайте рассмотрим пример и образец кода, демонстрирующий обсуждавшиеся до сих пор идеи.

Настройка исключений (с использованием библиотеки Enterprise Library)

Далее описан пример использования блока обработки исключений из библиотеки Enterprise Library для настройки исключений для приложения Windows Forms; подобный прием может применяться для других технологий пользовательских интерфейсов Microsoft .NET Framework.

Во-первых, следует централизовать обработку исключений посредством какого-нибудь специального класса ExceptionHandling, как показано на рис. 5. Это статический класс с методами, которые непосредственно сопоставляются определенным политикам исключений в структуре вашей библиотеки Enterprise Library.

Рис. 5. Класс ExceptionHandling

public static class ExceptionHandling
{
    public static Exception UiUnknown(Exception exception)
    {
        try
        {
            if (Microsoft.Practices.EnterpriseLibrary.
                ExceptionHandling.ExceptionPolicy
                  .HandleException(exception, "UiUnknown"))
                return exception;
        }
        catch (Exception ex)
        {
            return ex;
        }
        return null;
    }
}

Настройте эту политику в средстве настройки библиотеки Enterprise Library Configuration, как показано на рис. 6. Укажите два типа обработчиков, в большой степени так, как это можно было бы сделать в операторе try/catch. Выбирается более специфический обработчик. В обоих случаях можно сначала зарегистрировать созданное исключение с помощью встроенного средства форматирования исключений XML с использованием прослушивателя отслеживания ведения журналов XML. В случае общего исключения можно исходное исключение обернуть в новое исключение, снабженное сообщением, ориентированным на пользователя. Альтернативным вариантом является его замена, но на тот случай, если пользовательскому интерфейсу требуются подробные сведения о фактическом исключении, возможно, разумнее обернуть его.

fig06.gif

Рис. 6 Средство настройки библиотеки Enterprise Library

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

Если требуется, чтобы вызывающий код выполнял дополнительные действия по поводу исключений, еще один вариант состоит в выборе NotifyRethrow, который приводит к тому, что EntLib ExceptionPolicy.HandleException возвращает значение true. Как вы далее увидите, в случае DatabaseConnectivityException всё, что относится к пользователю, можно обработать в исключении пользовательского типа, поэтому всё, что предыдущая политики для этого делает, это регистрация и уведомление о том, что оно должно быть создано повторно.

Вызвав ExceptionHandling.UiUnknown, вы получаете новое, обернутое исключение, исходное исключение или не получаете ничего, если в политике принято решение не создавать новое исключение и не уведомлять о необходимости повторного создания исключения. Это является основным преимуществом блока обработки исключений: политики можно настраивать вне кода приложения (хороший способ вывести эту общую задачу за пределы кода приложения). Затем исключение передается в метод ErrorMessage.Show, определенный в рис. 7 на форме ErrorMessage.

Рис. 7 Форма ErrorMessage

public static void Show(Exception relatedException)
{
    ErrorMessage em = new ErrorMessage();
    if (relatedException == null)
    {
        em.problemDetailsContainer.Visible = false;
    }
    else
    {
        em.problemDescription.Text = relatedException.Message;
        IUIExceptionDetail detail = 
          relatedException as IUIExceptionDetail;
        if (detail == null)
        {
            em.errorCode.Text = "500";
            em.problemDetails.Visible = false;
        }
        else
        {
            em.errorCode.Text = detail.ErrorCode.ToString();
            em.problemDetails.Text = detail.DetailMessage;
        }
        em.problemType.Text = 
          em.GetMeaningfulExceptionType(relatedException).Name;
        em._SearchText = em.errorCode.Text + " " + em.problemType.Text;
    }
    em.ShowDialog();
}

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

Если исключение не предоставляется, контейнер детализации скрыт — не имеет смысла вводить пользователя в заблуждение относительно наличия сведений, если они отсутствуют. (В таком случае можно даже не отображать сообщение.) Если исключение существует, следует настроить описание неполадки для сообщения об исключении. Затем следует проверить, реализует ли исключение данного типа пользовательский интерфейс IUIExceptionDetail.

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

public interface IUIExceptionDetail
{
    int ErrorCode { get; }
    string DetailMessage { get; }
}

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

Рис. 8. Исключение DataConnectivityException

public class DatabaseConnectivityException 
  : Exception, IUIExceptionDetail
{
    public DatabaseConnectivityException(Exception innerException)
     : base(Resources.Exceptions.DatabaseConnectivityException_Message, 
                innerException)
    {
        int.TryParse(
          Resources.Exceptions.DatabaseConnectivityException_Code,
          out _ErrorCode);
        _DetailMessage = 
           Resources.Exceptions
             .DatabaseConnectivityException_DetailMessage;
    }

    #region IUIExceptionDetail Members
    int _ErrorCode;
    public int ErrorCode
    {
        get { return _ErrorCode; }
    }

    string _DetailMessage;
    public string DetailMessage
    {
        get { return _DetailMessage; }
    }
    #endregion
}

Наиболее интересным здесь является использование файла RESX для хранения сообщения, кода ошибки и подробных сведений. Это предусмотрено для локализации, но служит также в качестве удобного источника XML для документации по сообщениям об ошибках — можно без труда применить XSLT к формату RESX для получения HTML или другой разметки форматированного текста.

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

Возвращаясь к методу ErrorMessage.Show, можно заметить проверку на наличие интерфейса IUIExceptionDetail. Если он обнаруживается, он использует дополнительную предоставленную информацию для отображения ее пользователю. В противном случае диалоговое окно подробных сведений скрывается, и отображается обобщенный код ошибки 500 (подобно HTTP 500).

Результат для случая общей/неизвестной ошибки показан на рис. 9. В случае более конкретной ошибки, такой как DataConnectivityException, вы получаете сообщение, подобное сообщению на рис. 10.

fig09.gif

Рис. 9 Сообщение об общей ошибке

fig10.gif

Рис. 10 Сообщение о более конкретной ошибке

Здесь необходимо обратить внимание на несколько моментов. Первый из них — это крайне последовательное соблюдение рекомендаций по работе с Windows Vista для сообщений об ошибках. Окно является модальным диалоговым окном. Заголовок диалогового окна ясно сообщает пользователям о том, какой компонент создает ошибку, чтобы они не спутали ее, например, с системными ошибками; это может быть также специальным компонентом приложения. В окне имеется заметный индикатор с крупным значком, указывающий на то, что речь идет об ошибке, который перекрывает логотип приложения, и выполняет две функции — выделения источника неполадки и одновременно явного указывая на то, что это ошибка. Текст заголовка также явно сообщает пользователю, что в приложении имеется неполадка.

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

fig11.gif

Рис. 11 «Сообщите нам о неполадке» — кнопка, рекомендуемая Амброзом Литлом (Ambrose Little)

Кнопка ссылки «Поиск решений в Интернете» запускает поиск с использованием «MSDN Magazine» плюс ошибка и тип исключения. Это удобная функция, поскольку пользователи могут не понимать, что следует поместить в поле поиска. Если на вашем узле имеется раздел технической поддержки пользователей, можно также ограничить поиск пределами вашего узла. И, безусловно, если у вас имеется специальная служба поиска (на основе кода), ее следует предпочесть общей процедуре поиска по ключевым словам.

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

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

Реализовав это, можно добавить обработчик уровня приложения в метод Program.cs Main следующим образом.

Application.ThreadException += Application_ThreadException;

Этот метод выглядит следующим образом.

static void Application_ThreadException(object sender, 
  System.Threading.ThreadExceptionEventArgs e)
{
    ErrorMessage.Show(ExceptionHandling.UiUnknown(e.Exception));
}

Он перехватывает все непредвиденные исключения пользовательского интерфейса и направляет их посредством политики «UiUnknown» в класс централизованного обработчика исключений, который в данном примере делегирует обработку библиотеке Enterprise Library, хотя это могла бы быть любая имеющаяся платформа обработки исключений. Потенциально, этот метод возвращает исключение для отображения посредством более понятной пользователю формы ErrorMessage, разработанной вами. И, конечно, подобный подход можно использовать в рамках всего приложения для более специальных политик исключений.

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

Др. Чарльз Крейтцберг (Dr. Charles Kreitzberg) – генеральный директор компании Cognetics Corporation, предоставляющей консультации по удобству использования и проектированию взаимодействия с пользователями. Его страстью является создание интуитивных интерфейсов, завлекающих и радующих пользователей и в то же время поддерживающих деловые задачи продукта. Чарльз живет в центральном Нью-Джерси, где подрабатывает музыкантом-исполнителем.

Эмброз Литтл (Ambrose Little) живет со своей женой и четырьмя детьми в центральном Нью-Джерси. Он занимается проектированием и разработкой программного обеспечения в течении более чем 10 лет и удостоился чести стать спикером INETA, а также обладателем звания наиболее ценного специалиста (MVP) Майкрософт. В последнее время он перешел с технической разработки к разработке для публики и является сейчас проектировщиком взаимодействия с пользователем для Infragistics.