Стратегии обработки исключений WCF
Мы разрабатываем прокси в WCF, который будет служить средством сообщения для некоторых карманных компьютеров, выполняющих наше пользовательское клиентское приложение. Мне любопытно, что используют люди стратегий обработки ошибок, поскольку я не обернул бы КАЖДЫЙ вызов прокси в попытку/выгоду.
Когда я разрабатываю.NET ASP, я не ловлю большинство исключений, я усиливаю Application_Error в Глобальном asax, который может тогда зарегистрировать исключение, послать электронное письмо и перенаправить пользователя к пользовательской ошибочной целевой странице. То, что я ищу в WCF, подобно этому, за исключением того, что он позволил бы мне передавать общий faultreason клиенту от центрального расположения.
В основном мне любопытно, как люди централизуют свою обработку исключений в приложениях WCF.
Спасибо
3 ответа
Вы можете найти здесь интерфейс IErrorHandler . Мы использовали это, чтобы делать в значительной степени то, что вы упомянули - централизованное ведение журнала исключений и предоставление общих причин сбоя без необходимости засорять код многочисленными попытками / уловками, чтобы попытаться решить проблему локально.
Мы используем блок приложения для обработки исключений и защищаем большинство ошибок от клиентов, чтобы избежать раскрытия конфиденциальной информации. Эта статья может быть хорошим началом точка для вас, как и в случае с "лучшими практиками" - вы должны использовать то, что подходит для вашего домена.
Итак, вот что я сделал. У нас есть несколько пользовательских исключений в нашем приложении, таких как BusinessRuleException и ProcessException, WCF поддерживает как FaultException, так и FaultException.
Общая практика, кажется, состоит в том, что вы всегда бросаете FaultException клиенту в случае общей ошибки или ошибки, которую вы не хотите отображать точно, что произошло. В других случаях вы можете передать FaultException, где T - класс с информацией о конкретном исключении.
Я создал концепцию нарушений в приложении, которая в основном означала, что любое пользовательское исключение имело свойство, содержащее соответствующий экземпляр нарушения. Этот экземпляр затем передавался клиенту, позволяя клиенту распознать, когда произошла ошибка, которую можно устранить.
Это частично решило проблему, но мне все еще нужен был общий экземпляр, который позволил бы мне централизовать логирование. Я нашел это, используя интерфейс IErrorHandle и добавив свой собственный обработчик ошибок в WCF. Вот код:
public class ServiceHostGeneralErrorHandler : IErrorHandler
{
public void ProvideFault(Exception ex, MessageVersion version, ref Message fault)
{
if (ex is FaultException)
return;
// a general message to the client
var faultException = new FaultException("A General Error Occured");
MessageFault messageFault = faultException.CreateMessageFault();
fault = Message.CreateMessage(version, messageFault, null);
}
public bool HandleError(Exception ex)
{
// log the exception
// mark as handled
return true;
}
}
Используя этот метод, я могу преобразовать исключение из того, чем оно является, во что-то, что может быть легко отображено на клиенте, и в то же время регистрировать настоящее исключение, чтобы ИТ-персонал мог его увидеть. Пока этот подход работает достаточно хорошо и соответствует той же структуре, что и другие модули в приложении.