Где захватить неудавшееся соединение на WCF вызов класса?

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

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

Вот почему вы все еще получаете исключение - здесь оно не обрабатывается.

Обновление:

Судя по трассировке стека, похоже, что фреймворк пытается выполнить ваш делегат обратного вызова и получает исключение. В другом месте вы ответили, что попытка / перехват содержимого вашего делегата не решает проблему ... как насчет внутренних исключений? Каков полный вывод TheException.ToString ()?

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

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

public class ProxyWrapper : IDisposable
{
    private IDirector proxy;
    private ChannelFactory<IDirector> factory;
    int callCount = 0;

    public ProxyWrapper()
    {
        factory = new ChannelFactory<IDirector>();

        proxy = factory.CreateChannel();
    }

    public IDirector Proxy
    {
        get
        {
            if (callCount > 0)
                throw new InvalidOperationException("The proxy can only be accessed once for every ProxyWrapper instance. You must create a new ProxyWrapper instance for each service request.");
            // only allow the proxy/channel to be used for one call.

            callCount++;
            return proxy;
        }
    }

    public void Dispose()
    {
        IClientChannel channel = (IClientChannel)proxy;

        try
        {
            if (channel.State != CommunicationState.Faulted)
            {
                channel.Close();
            }
            else
            {
                channel.Abort();
            }
        }
        catch (CommunicationException)
        {
            channel.Abort();
        }
        catch (TimeoutException)
        {
            channel.Abort();
        }
        catch (Exception)
        {
            channel.Abort();
            throw;
        }
        finally
        {
            channel = null;
            proxy = null;
        }
    }
}

Способ использования вышеуказанного класса следующий:

    public static void Login(string userName, string password)
    {
        using (ProxyWrapper wrapper = new ProxyWrapper())
        {
            currentSession = wrapper.Proxy.Login(userName, password);
        }
    }

Поскольку ProxyWrapper класс реализует IDisposable , если мы используем экземпляр класса ProxyWrapper внутри с использованием блока , метод Dispose () гарантированно вызывается, даже если возникает исключение. Код в методе Dispose () будет обрабатывать все случаи и состояния прокси / канала. Затем вы можете добавить в этот метод код делегата обработки ошибок / ведения журнала / событий.

Прочтите следующую запись в блоге для получения дополнительной информации и более общей версии приведенного выше кода: http://bloggingabout.net/blogs/erwyn/archive/2006/12/09/WCF-Service- Proxy-Helper.aspx

Чтобы выявить ошибки связи с сервером, я бы предложил позвонить по адресу .CreateChannel () в попытке ... поймать и обработать такие вещи, как CommunicationException и TimeoutExceptions.

Кроме того, один самый главный совет: создание ChannelFactory - довольно дорогостоящая операция, поэтому вы можете захотеть сделайте это отдельно и сохраните эту ссылку на объект ChannelFactory где-нибудь.

Если вам нужно создать и, возможно, повторно создать канал из ChannelFactory, вы можете затем снова и снова использовать этот сохраненный / кэшированный экземпляр ChannelFactory, не имея создавать это все время.

Но в остальном, я думаю, у вас здесь все хорошо!

Marc

Джефф, пожалуйста, покажите нам ваш код, когда вы пытаетесь поместить блок try / catch вокруг вызова EndGet. Трудно поверить, что это не перехватывает исключение, и это поможет мне поверить.

Кроме того, как часть этого эксперимента, избавьтесь от обработчика события UnhandledException. Я думаю, вы поймаете это исключение, как только BrowserHttpRequest поймет, что есть 404. Я думаю, что без события UnhandledException попытка / уловка EndGet перехватит исключение, если оно есть. Я думаю, вы выбрали промежуточное состояние процесса обработки исключений.

Я также хотел бы, чтобы вы поместили System.Debugger.Break или что-то еще сразу после вызова EndGet.

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

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

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

public static void Invoke<TContract>(ChannelFactory<TContract> factory, Action<TContract> action) where TContract : class {

    var proxy = (IClientChannel) factory.CreateChannel();
    bool success = false;
    try {
        action((TContract) proxy);
        proxy.Close();
        success = true;
    } finally {
        if(!success) {
            proxy.Abort();
        }
    }
}

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

Примечание - только реальный канал нуждается в этой специальной обработке. Вы можете избавиться от фабрики любым удобным для вас способом, AFAIK.

Я думаю, что проблема в том, как вы спроектировали вызывающую службу.

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

Я бы перенес создание и закрытие канала в метод вызова make.

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