Silverlight 2, WCF et les FaultException

Lorsque une équipe travaille en Silverlight, il est nécessaire de communiquer avec un proxy (serveur) pour disposer de données et interagir avec elles.
Pour se faire, nous pouvons utiliser les objets WebRequest ou WebClient (tuto : http://bdevuyst.developpez.com/tutoriels/silverlight/S2-interagir-avec-son-serveur/).

Nous pouvons également utiliser WCF (Windows Communication Fundation). Pour rappel, cette technologie permet de ne maitriser qu'une seule syntaxe (en C#, par exemple), et un fichier de paramètres permettra à WCF de savoir quel est le protocole à utiliser pour les échanges (WebService, NetPipes, ...).

Lorsque l'on manipule du WCF, les exceptions rencontrées sur le serveur peuvent être transférées au client grâce à la classe FaultException (Il s'agit d'une Exception qui peut être sérialisée vers un client).
Tout autre Exception (dérivant de System.Exception) se voit arrêtée par WCF côté serveur.
En effet, pour des raison de sécurité, une System.Exception ne peut traverser WCF.
(Elle contient trop d'informations sur l'architecture de l'application - stacktrace par exemple).

Suite à un souci (l'explication est à trouver ici : msdn), ces erreurs ne peuvent être remontées vers le client Silverlight 2 (ce sera peut être le cas en version 3).

Dès lors, pour pouvoir gérer, côté Silverlight, les exceptions éventuelles de l'application serveur, il faut être un petit peu sioux !

Voici le lien d'une solution Visual Studio 2008, proposant une réponse à ce problème :
ftp://ftp-developpez.com/bdevuyst/tutoriels/silverlight/S2-gestion-exception-wcf/SilverlightApplicationGstException.zip

Globalement, voici le mécanisme :

La solution est divisée en 3 projets :
- Le projet Web qui héberge l'application Silverlight et un Service WCF (.svc),
- Le projet Silverlight,
- Un projet bibliothèque de classe qui "simule" une autre couche, qu'utilise le Service WCF,

1. L'application Silverlight appelle le point de terminaison WCF, (derrière le bouton),
2. L'application WCF traite la demande, cherche à obtenir les données, et une exception se produit... (pas de chance ;) )
3. La couche WCF catch l'exception, et retourne un objet d'un type particulier
4. Cet objet retourné est la clé du mécanisme

Il s'agit d'une classe générique qui contient 3 propriétés :

• Message : Correspond au message de l'exception générée, vide si le traitement s'est bien passé,

• StackTrace : Pour le debug (dans le cas de symbole de debuggage absent, ce champ est vide)

• ObjetAttendu dont le type est précisé lors de la déclaration de la variable. Cette dernière contiendra l'objet attendu si aucune exception ne s'est produite pour le récupérer.

L'application Silverlight récupère alors un objet qui contient les trois propriétés, et peut donc déterminer si une exception s'est produite, et si un résultat est exploitable.

Je vous invite à télécharger les sources pour bien saisir le mécanisme...
Lien des source de la solution Visual Studio 2008 :
ftp://ftp-developpez.com/bdevuyst/tutoriels/silverlight/S2-gestion-exception-wcf/SilverlightApplicationGstException.zip

@+