Двусторонняя операция службы WCF не возвращает ответа вместо исключения

Question

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

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

Форматер выдал исключение при попыткедля десериализации сообщения: при попытке десериализации параметра * 1007 произошла ошибка * Сообщение InnerException было «Произошла ошибка при десериализации объекта типа Organization.Division.Application.Service.AddNewItem. Превышена максимальная квота на длину содержимого строки (8192) при чтении данных XML .Эту квоту можно увеличить, изменив свойство MaxStringContentLength в объекте XmlDictionaryReaderQuotas, используемом при создании средства чтения XML.Строка 1, позиция 20157. '.

Проблема заключается в том, что служба не возвращает это исключение; вместо этого служба генерирует исключение ArgumentNullException с сообщением об исключении:

Значение не может быть нулевым.Имя параметра: message

... и мой клиент просто выдает мне эту ошибку (это верно, является ли мой клиент веб-страницей ASP.NET, тестовым клиентом WCF или другими):

Не удалосьвызвать службу.Возможные причины: служба недоступна или недоступна;конфигурация на стороне клиента не соответствует прокси;существующий прокси-сервер недействителен.Обратитесь к трассировке стека для более подробной информации.Вы можете попытаться выполнить восстановление, запустив новый прокси-сервер, восстановив конфигурацию по умолчанию или обновив службу.Детали ошибки:Произошла ошибка при получении ответа HTTP на http://localhost/Services/MyAwesomeS3rv1c3/DoSomethingGrrreat.svc. Это может быть связано с тем, что привязка конечной точки службы не использует протокол HTTP.Это также может быть связано с тем, что сервер прерывает контекст HTTP-запроса (возможно, из-за закрытия службы).Дополнительные сведения см. В журналах сервера.

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

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

Для дополнительной справочной информации у меня установлены следующие настройки в <serviceBehavior><behavior>... в web.config службы:

<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>

...и я использую привязки wsHttpBinding и mex.

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

Answer 1

В моем случае я использовал Enterprise Library для регистрации исключений. Конфигурация для регистрации была, очевидно, неверной. Однако это не было обнаружено трассировкой службы WCF.

Трассировка действительно показывала основное исключение (ошибка SQL или иное), которое было правильно обработано / перехвачено. После этого Сервисный канал необъяснимо закрывался. ArgumentNullException был создан, поскольку не было никакого ответного сообщения, чтобы возвратиться.

Все это произошло из-за исключения в обработке ошибок базового исключения, которое никогда не отображалось в трассировке. Отладка службы показала, что Microsoft.Practices.EnterpriseLibrary.Logging.Logger.Write фактически выдавало свое собственное исключение, которое было необработанным и скрыто от просмотра. Исправление этого исключения (или просто временное отключение ведения журнала & mdash;) исправило проблему.

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

Answer 2

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