Лучшие практики при сообщении сообщений об исключениях пользователю

Question

В моем приложении ASP.NET MVC я не хочу сообщать пользователю обо всех сообщениях об исключениях. Но есть определенные типы исключений, о которых я хотел бы сообщить пользователю, поэтому я создал фильтр действий, чтобы решить, является ли это конкретным типом исключения, и если да, то отобразить сообщение об исключении, в противном случае отобразить общее сообщение. Поэтому я создал собственное исключение под названием ClientException.

Мой фильтр выглядит примерно так:

    if (filterContext.Exception is ClientException)
         message = filterContext.Exception.Message.Replace("\r", " ").Replace("\n", " ");
   else
        message = "An error occured while attemting to perform the last action.  Sorry for the inconvenience.";

    filterContext.HttpContext.Response.Status = "500 " + message;

Я прочитал это http://blogs.msdn.com/b/kcwalina/archive/2007/01/30/exceptionhierarchies.aspx, где автор рекомендует использовать существующие типы исключений .NET для сообщения об ошибках использования. Однако, вводя свое пользовательское исключение, я просто должен сделать одну проверку в своем фильтре. Мой подход в порядке?

Answer 1

Мне нравится этот подход по нескольким причинам.

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

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

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

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

Так что, на мой взгляд, это хороший дизайн.

Answer 2

Ваш подход хорош для ИМО, но есть альтернативы. (Мы разработчики программного обеспечения, поэтому всегда есть альтернативы.)

Вы можете использовать словарь Exception Data для хранения флага, указывающего, является ли исключение клиентским исключением. Затем вы можете проверить фильтр на наличие флага.

Answer 3

Мое беспокойство в связи с этим решением заключается в том, что эти исключения, скорее всего, будут выбрасываться объектами бизнес-уровня (или объектами модели в терминологии MVC). Использование, которое вы описываете, действительно то, что я считаю проблемой презентации.

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

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

Answer 4

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

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

Answer 5

Если ваш подход работает для вас, тогда это нормально. И вы удивлены тем, что блог Microsoft рекомендует использовать их исключительный класс? ;)

Существуют некоторые функции библиотеки .NET и сторонние OSS, которые могут работать только с исключениями .NET.

Чтобы получить лучшее из обоих миров, вы всегда можете расширить объект .NET Exception на свой собственный.