Форматировать сообщения об исключениях, используя InvariantCulture или CurrentCulture? - PullRequest
3 голосов
/ 07 июля 2010

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

Вот пример:

throw new InvalidOperationException(
    string.Format(
        CultureInfo.CurrentCulture,
        "{0} is a bad number.",
        number));

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

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

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

Так что вы думаете по этому поводу?

Ответы [ 2 ]

5 голосов
/ 07 июля 2010

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

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

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

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

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

1 голос
/ 03 мая 2011

ИМХО, вы можете использовать свойство «Данные» класса исключений.Таким образом, вы можете сохранить в свойстве «Message» инвариантное сообщение, которое вы хотите зарегистрировать.И вы можете добавить в коллекцию «Данные» значение пары ключей с помощью Key = "UIMessage" и Value = ваше сообщение пользовательского интерфейса, правильно отформатированное в соответствии с культурой пользователей (и может быть ваше сообщение переведено в соответствии с правильной культурой).В вашем обработчике исключений вам может потребоваться выбрать между свойством Message и парой данных, чтобы регистрировать или отображать правильное сообщение.

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