Лучший способ поймать исключение WCF в Silverlight?

Ответ 1

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

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

Ответ 2

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

• В обычном коде .NET сгенерированный класс прокси обрабатывает исключение должным образом, помещая исключение в свойство Error, а не бросая его.

• В Silverlight созданный класс прокси устанавливает свойство Error, но не полностью обрабатывает исключение. Исключение выбирается отладчиком, который выдает окно исключения с сообщением "Исключение ProtocolException было не обработано кодом пользователя". Несмотря на это сообщение, исключение не похоже на функцию Application_UnhandledException.

Я бы ожидал, что это одна из вещей, которые они исправят в финальной версии.

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

Ответ 3

Вы можете забыть о Application_UnhandledException для обратных вызовов клиента asyn, почему:

Application_UnhandledException только исключения, запущенные в потоке пользовательского интерфейса, могут быть захвачены Application.UnhandledExceptions

Это означает, что... не вызывался вообще для асинхронного вызова WCF: -).

Проверить подробный ответ от MSFT

http://silverlight.net/forums/t/21828.aspx

Здравствуйте, только исключения, запущенные в потоке пользовательского интерфейса, могут быть захвачены Application.UnhandledExceptions. Он не может перехватывать исключения из других потоков. Вы можете попробовать это, чтобы устранить проблему: в Visual Studio из меню Debug выберите "Исключения". Затем установите флажок "Исключения общего времени выполнения языка". Это заставит отладчик останавливаться всякий раз, когда генерируется исключение. Но обратите внимание, что это может быть довольно неприятно, потому что даже если исключение уже поймано. Вы можете использовать CheckBoxes для фильтрации исключений, которые вы хотите поймать.

Хорошая новость в моем случае заключается в том, что обработка сообщения об ошибке только в обратном вызове службы clietn достаточно, если вы не отлаживаете.

Спасибо

Braulio

Ответ 4

OOpps....

Извините неправильный ответ с моей стороны (ну, парень MSFT не попал в ответ на вызов службы ответа, вызываемые вызовы в одном и том же потоке пользовательского интерфейса), вещь

Дополнительная информация:

- In development even detaching from the debugger, this method is never reached. 
- On the production environment yes.

Мое предположение связано с параметрами Visual Studio и перехватами исключений.

Дополнительная информация, в этой теме http://silverlight.net/forums/p/48613/186745.aspx#186745

Довольно интересная тема.

Ответ 5

Я не сантехник, поэтому решил создать свой собственный класс сервисов WCF, который переопределяет некоторые функциональные возможности файла класса "reference.cs", который автоматически генерируется Visual Studio, затем я добавил свой собственный try/блоки захвата для обнаружения ошибок связи.

Созданный мной класс выглядит примерно так:

public class myWCFService : MyWCFServiceClient
{

    protected override MyController.MyService.IMyWCFService CreateChannel()
    {
        return new MyWCFServiceClientChannel(this);
    }

}

private class MyWCFServiceClientChannel : ChannelBase<MyController.MyService.IMyWCFService>, MyController.MyService.IMyWCFService
{
    /// <summary>
    /// Channel Constructor
    /// </summary>
    /// <param name="client"></param>
    public MyWCFServiceClientChannel(System.ServiceModel.ClientBase<MyController.MyService.IMyWCFService> client) :
    base(client)
    {
    }
    /// <summary>
    /// Begin Call To RegisterUser
    /// </summary>
    /// <param name="memberInformation"></param>
    /// <param name="callback"></param>
    /// <param name="asyncState"></param>
    /// <returns></returns>
    public System.IAsyncResult BeginRegisterUser(MyDataEntities.MembershipInformation memberInformation, System.AsyncCallback callback, object asyncState)
    {               
        object[] _args = new object[1];
        _args[0] = memberInformation;
        System.IAsyncResult _result = base.BeginInvoke("RegisterUser", _args, callback, asyncState);
        return _result;               
    }
    /// <summary>
    /// Result from RegisterUser
    /// </summary>
    /// <param name="result"></param>
    /// <returns></returns>
    public MyDataEntities.MembershipInformation EndRegisterUser(System.IAsyncResult result)
    {
        try
        {
            object[] _args = new object[0];
            MyDataEntities.MembershipInformation _result = ((MyDataEntities.MembershipInformation)(base.EndInvoke("RegisterUser", _args, result)));
            return _result;
        }
         catch (Exception ex)
        {
            MyDataEntities.MembershipInformation _result = new MyDataEntities.MembershipInformation();
            _result.ValidationInformation.HasErrors = true;
            _result.ValidationInformation.Message = ex.Message;
            return _result;
        }
    }
}

Ответ 6

С Silverlight 3 отладчик Visual Studio ловит эти исключения, так что обработчик исключений - смутно - никогда не достигается. Однако при запуске без отладчика обработчик исключений вызывается как ожидалось. Я думаю, это нормально, если вы это осознаете. Я признаю, что потратил несколько часов, пытаясь понять, как развернуть внутреннюю работу Silverlight/Wcf/Browser, чтобы добраться до моего исключения. Не ходите туда.

Ответ 7

Использование настраиваемого генератора прокси-сервера WCF является хорошим решением для обработки асинхронных исключений в Silverlight.Click здесь для загрузки исходного кода.

Ответ 8

С XNA на WP7 я обнаружил, что у меня не было выбора, кроме как вручную добавить try/catch в различные методы async End * FunctionName *(); ничто другое, что я пытался, предотвратит сбой приложения и завершение работы, когда сервер будет недоступен. Это реальное перетащить, чтобы вручную обновить этот код при изменении службы.

Я удивлен, что это не большая проблема, поскольку, похоже, нет никакого другого способа поймать эти исключения на WP7, используя XNA, но я полагаю, что это просто говорит о том, сколько людей (== не многие) пытаясь сделать это, чем что-либо еще. Если бы они просто сделали slsvcutil.exe генерировать методы синхронизации, мы могли бы легко поймать их внутри нашего собственного рабочего потока, но, к сожалению, сгенерированный код использует потоки пула потоков, не имея возможности поймать исключения.

Ответ 9

Чтобы справиться с этой ситуацией, используйте исключение TargetInvocationException. Это поймает исключение, если сеть не работает или ваша служба недоступна.