Я использую WCF netNamedPipeBinding и wsHttpBinding. Я хотел бы знать, может ли односторонний метод успешно выполнить без использования try.Как определить подключение WCF без try-catch?
EDIT Как заметил кто-то, успех может преуспеть в данный момент, а в следующий провал. Мне все равно. Я просто хочу знать, есть ли у WCF альтернатива try ing. Есть ли способ проверить, действительно ли сервис доступен и доступен?
К моему knoweldge единственный способ определить, успешно ли выполнен односторонний метод, является ли он генерирующим исключение.
Если метод не является односторонним, вы можете вернуть обратно логическое значение, которое указывает, был ли метод неудачным или не удалось.
Могу я спросить, почему вы пытаетесь это сделать? Не вылавливая исключение в методе, невозможно определить условия ошибки, если исключение не существует.
Если я не понимаю ваше использование «попытки», и вы имеете в виду, что не выполняете этот метод, вы можете написать прокси для метода, который на самом деле не совершает действие, только шаг обработки.
Если вы делаете это для целей полного тестирования, я хотел бы рекомендовать использовать модульные тесты Visual Studio или подключить ваш проект к NUnit.
Просьба представить более подробную информацию о том, что вы пытаетесь выполнить, если один из указанных выше пунктов не ответил на ваш вопрос.
EDIT: модифицировано для учёта разъяснений.
using(YourService svc = new YourService()){
if(svc.State.Equals(!CommunicationState.Opened)){ /*Handle Error*/ }
svc.InnerChannel.Faulted += new EventHandler(YourFaultedEventHander);
}
будет охватывать вас, чтобы увидеть, если соединение в настоящее время открыт и уведомляет вас, если/когда услуга переходит в поврежденном состоянии. Это будет предупреждать вас о том, будет ли вызов успешным. Тем не менее, все еще существуют условия, которые могут привести к сбою определенного метода. Это только сообщит вам, если вы можете успешно вызвать метод службы.
Я хочу знать, работает ли служба, и есть ли связь между клиентом и службой. –
Идеальное объяснение сейчас, желание, которое было в начальном посте, и я мог бы ответить на то, что я опубликовал в своем предыдущем редактировании на начальном этапе ;-) – VulgarBinary
Невозможно узнать, будет ли успешным вызов в одностороннюю операцию; односторонние операции (AFAIK) поддерживаются на всех привязках.
Если вы хотите просто определить, является ли вызов односторонней, то вам придется выполнять итерацию по операциям описания службы (вы не указываете, является ли это вызовом на стороне клиента или сервера) и посмотрите, является ли операция одним из способов.
Я знаю заранее, если операция является односторонней. Я только упомянул об этом как односторонний, потому что я забочусь только о соединении, а не о том, что сервер бросил исключения. –
@Jader Dias: Без звонка вы не можете сказать; в WCF нет встроенной функции «ping».Вы * можете * вызывать метод 'Open' на прокси-сервере до того, как вы сделаете свой вызов, но в зависимости от привязки этот вызов может означать разные вещи, единственное, что гарантирует звонок, - это то, что прокси-сервер может получать сообщения. – casperOne
Это не совсем так, да, открытый вызов может иметь разные значения в зависимости от привязки (думаю, подходящий вопрос здесь заключается в том, чтобы спросить, что именно используется Jader), но вы можете больше рассказать о клиенте службы без звонка. Событие сбоя (которое охватывает случай, когда клиентский канал поврежден до данного вызова) и определяет, открыт ли канал в настоящий момент. Который, как вы сказали, гарантирует только, что прокси-сервер готов принимать запросы ... но он по-прежнему дает статус услуги, кроме того, что делает звонок слепым. – VulgarBinary
Что произойдет, если вы протестируете вызов, он пройдет, то каким-то образом связь прекратится и ваш следующий блок кода не удастся? Вам лучше сходить try, а затем обрабатывать ошибку, если/когда она появится.
Кто-то, наконец, понял вопрос –
Я согласен, что ВСЕГДА придется обрабатывать вызов службы с уловкой, но есть способы (как я упоминал в своем сообщении) определить текущее состояние службы, а также активировать события для захвата ошибочные состояния. Независимо от того, вы должны ВСЕГДА попробовать {...} уловить (..) {...} ваши служебные вызовы независимо от того, насколько вы защищаете переднюю защиту. – VulgarBinary
@JaderDias, если у сообщества возникли проблемы с пониманием вопроса, подумайте, что вопрос может быть плохой для сообщества. – Gusdor
Хорошо, так что, если метод работает прямо сейчас. Таким образом, вы называете метод, но он снизился тем временем? Будет ли у вас приложение просто сбой, или вы будете использовать блок try/catch? –
См. Обновление в моем первоначальном комментарии. Он охватывает уведомление о неисправном состоянии, а также определение текущего состояния служб. – VulgarBinary