Discussion :

[NeoMan]

Bonjour à tous!

Je cherche désespérément depuis ce matin une réponse à une question qui me parait pourtant simple : comment gérer une exception émise depuis un IValueConverter ?

Prenons un cas concret et très simple :
- Le converteur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
 
    public class GlobalConverter : IValueConverter
    {
        object IValueConverter.Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            return System.Convert.ChangeType(value, targetType, culture);
        }
 
        ...
    }

- L'utilisation dans le binding :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<UserControl ...>
    <Grid>
        <TextBox Grid.Column="1" Grid.Row="1" Text="{Binding FloatProperty, Converter={StaticResource GlobalConverter}, Mode=TwoWay, ValidatesOnExceptions=True, NotifyOnValidationError=true}" />        
    </Grid>
</UserControl>

En considérant que FloatProperty est de type float; et que je saisie "Valeur non float" dans mon textbox. A la perte du focus mon converter émettra l'exception FormatException : Le format de la chaîne d'entrée est incorrect.; ce qui est tout à fait normal. Seulement cette exception a tendance à planter complètement l'exécution de l'application Silverlight...

Mais comment faire, pour mettre le TextBox en erreur, avec le classique encadré rouge et un tooltip qui affiche l'erreur (avec un message compréhensible pour l'utilisation, donc que nous pussions gérer) ?

Merci d'avance pour vos lumières, car hormis une personnalisation du binding lui-même, je ne parviens pas à trouver d'autres solutions techniques!

[Kikuts]

Pour l'encadré rouge :

Plusieurs cas : ta saisie se retrouve dans un DataGrid, alors il te faudra oeuvrer dans l'event CellValidating et tester toi même la valeur. Si elle n'entre pas dans tes specs, alors tu fais e.IsValid = true (un truc du genre).

Si tu es dans un textbox, alors tu peux mettre un ValidateError à true dans ton xaml. et dans la propriété bindé sur la propriété Text, dans son setter, tu fais :

if (value < 0) then throw new exception ("Veuillez saisir une valeur supérieur à zéro") et le textbox récupérera le message qu'il insérera dans l'encadré rouge.



Je ne met rarement de la validation dans un converter. Un converter est pour moi un moyen de formater une donnée ou définir des propriétés dans l'interface avec des trucs comme ConverterBooleanToVisibility.

Pour ne pas planter tu peux mettre ton code du converter dans un try catch et gérer l'exception avec un return nothing dans le catch par exemple. Il faut que tu test ton type de donnée entrante car si tu bind sur un objet, si jamais ta variable/property (comme tu veux) passé dans le converter est à Null / Nothing (c#/vb) alors ta conversion peux lever une exception.

Par exemple : (je risque de mixer vb et c# c'est juste pour exemple car ça fait 6, 7 mois que je ne fais plus que du vb.net ...

Class ConverterBooleanToMessage : ivalueconverter (nom bidon juste pour montrer)
{

public Convert(.......................)
{
-if type of value is boolean then
--- if (value as boolean)
------- return "La commande est Ok"
--- else
------- return "erreur lors de la commande"
--- end if
-else
----debug.WriteLine("Erreur de type de donnée en entrée")
-end if
}
}


Une autre solution est de placer ta logique dans le getter de la property que tu bind pour être sur que la valeur d'entrée sera valide et ne fera pas planter ton converter.

Ca peut être get { if (_maProp = null) _maProp = new Object(); return _maProp; }

[NeoMan]

Merci beaucoup pour cette réponse.

Pour donner un peu de contexte, je ne suis pas en phase de réel développement. Mais c'était plutôt une question de bonne pratique d'architecture.

Comme toi, je ne suis pas fan de mettre des validations au sein d'un IValueConverter. Je ne parle ici que d'une émission d'exception au sein d'un converter. Cette exception étant généré dans le code du converter OU PAS!

Je vais être titilleux, mais dans ton exemple, il y a déjà un début de validation avec le "type of". Tu valides que la valeur satisfasse bien le fait que tu attends un booléen. Sinon tu agis en conséquence ici sans émettre d'exception.
Mais admettons le développeur du converter ne protège pas à fond son code; et cela génère une exception par le système (une NullReferenceException ou une FormatException). Alors dans ce cas, à l'exécution hors débuggage, l'erreur est complètement muette; ce qui est dommage en phase de recettage.

Donc sans pour autant vouloir mettre des (vraies) règles de validations dans les converter; on est tout de même susceptible d'avoir des exception. C'est pourquoi je me posais la question: comment les rendre visibles.

[Kikuts]

Alors pour qu'en version prod tu puisses être au courant qu'une erreur est survenue dans ton converter, admettons que tu utilises le système de Message, tu peux envoyer un message qui sera intercepté. Une fois intercepté, ton écouteur de message va transmettre via webservice ton erreur et ainsi tu pourras la sauvegarder dans un fichier xml, une base de données etc.

Pour revenir sur le test typeOf value, c'est juste un automatisme que j'ai gardé car un converter peut servir dans différents contextes :

ConverterToVisibility :

if type of value is string then
-- if value.tostring() = "oui" then return Visibility.Visible
-- else return visibility.Colapse
-- end if

elseif typeof value is integer then
-- return if((value as integer) = 0, Visibility.Collapse, Visibility.Visible)

elseif typeof value is datetime then
-- return if(DateTime.Parse(value.tostring() = datetime.Today), Visibility.Visible, Visibility.Collapse)

elseif typeof value is boolean
etc etc etc

Tu peux même tester la présence d'un parameterconverter qui retournera l'inverse des visibility (collapse au lieu de visible et inversement).

Dans ce genre de cas je préfère employer le terme de contrôle et non de validation. Car le type peut être bon mais la valeur non valide.

Par exemple if type of value is integer avec value représentant un age, théoriquement un age néatif n'a pas de sens. Pourtant le type de donnée sera correcte si value = -5. Avec expérience je sais que parfois on a pas le choix de déporter une partie de la validation dans le converter.

Maintenant, avec expérience quand la validation est obligatoire dans mon converter, si c'est possible,
je me passe de converter et je rajoute une property de type visibility (pour rester dans notre exemple) dans mon viewmodel et je bind dessus.

je ne connais pas les meilleurs pratiques mais après avoir utilisé les converter, on a tendance à les utiliser parfois dans des cas où l'on peut s'en passer facilement. Il faut en plus prendre en compte la ré utilisabilité d'un converter donc peut être bien de déporté un code dedans etc.

Exemple :

Public ReadOnly Property VisibilityUserControlCoquin
-- Get
---- Return if(_age >= 18, Visibility.Visible, Visibility.Collapase)
-- End Get
End property

Ainsi tu peux directement dans un if faire un appel WS pour loguer une erreur si age est null à un instant t sans passer par message ou autre (ou avec si ta plomberie est au point). Après ça dépend comme toujours du temps devant soit, de l'architecture déjà en place, des pratiques instaurées par ton équipe de développement.

Pour revenir à l'erreur muette, cela serait beaucoup trop contraignant pour l'utilisateur si ce n'était pas le cas. Imagine un datagrid où chaque cellule de chaque colonne représente une somme d'argent. Une erreur dans le converter t'afficherait nbColonne * NbLignes erreur car le converter sera utilisé pour l'affichage (même à l'initialisation) donc complétement bloquant et contraire à l'expérience utilisateur que doit apporter une RIA.