Le meilleur moyen d'attraper une exception WCF dans Silverlight?

J'ai trouvé un fil de discussion du forum qui a parlé de cela, et il mentionne que la meilleure pratique consiste à utiliser l'Erreur de la propriété. Entre ce fil et de mes propres expériences, c'est ce que je peux en conclure:

• Dans des conditions normales .NET code, le proxy généré classe gère l'exception correctement en mettant l'exception de l'Erreur de la propriété au lieu de la jeter.

• Dans Silverlight, le proxy généré classe définit l'Erreur de propriété, mais ne gère pas l'exception complètement. L'exception est capté par le débogueur, qui apparaît à l'exception de la boîte avec le message "ProtocolException a été gérée par le code de l'utilisateur". En dépit de ce message, l'exception ne semblent effectivement se rendre à l'Application_UnhandledException fonction.

Je m'attends que c'est l'une des choses qu'ils vont corrigé dans la version finale.

Pour l'instant, je vais utiliser la propriété Error et simplement de traiter avec le débogueur de rupture de l'exécution. Si elle devient trop gênant, je peux éteindre la pause sur une exception pour ProtocolException.

OOpps....

Désolé, pas de réponse de mon côté (bien MSFT gars n'a pas touché l'écrire répondre à des rappels de service sont appelés sur le même thread d'INTERFACE utilisateur), la chose est

Plus d'infos:

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

Je suppose que quelque chose en rapport avec les options de Visual Studio et de l'interception des exceptions.

Plus d'infos, dans ce fil
http://silverlight.net/forums/p/48613/186745.aspx#186745

Tout à fait intéressant.

Je ne suis pas un plombier, j'ai donc décidé de créer mon propre service WCF classe qui remplace une partie de la fonctionnalité de la classe fichier de référence.cs" qui est automatiquement généré par Visual Studio, j'ai ensuite ajouté mes propres blocs try/catch pour rattraper les erreurs de communication.

La classe que j'ai créée ressemble à quelque chose comme ceci:

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;
}
}
}

Avec XNA sur WP7, j'ai constaté que je n'avais pas le choix mais pour ajouter manuellement des try/catch pour les différents async Fin*FunctionName*() méthodes; rien d'autre, j'ai essayé permettrait d'éviter l'échec de l'application & à l'arrêt quand le serveur est indisponible. C'est un vrai glisser manuellement les mise à jour de ce code lorsqu'un service de change.

Je suis surpris de découvrir que ce n'est pas un gros problème car il ne semble pas y avoir d'autre moyen d'attraper ces exceptions sur WP7 à l'aide de XNA, mais je suppose que c'est seulement dit plus sur la façon dont beaucoup (==pas beaucoup) de gens essaient de faire ce que d'autre chose. Si ils serait tout simplement faire slsvcutil.exe générer des modes de synchronisation, on pourrait facilement attraper au sein de notre propre thread de travail, mais malheureusement, le code généré utilise le pool de threads ayant pas les moyens d'intercepter les exceptions.