Discussion :

[dkmix]

Bonjour,
Discussion intéressante car je suis en train de mettre en place une politique d'exception pour nos futurs développements.

Concernant l'exemple de Kropernic,

Code :

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

1
2
3
4
 
If dlg.Nickname.ToLower = "channel" Then
      Throw New CustomException("Désolé mais ce pseudo n'est pas ...")
End If

je ne suis pas d'accord, simplement car selon moi le test de NickName doit être fait dans l’événement Validating du formulaire DlgConnection.
Si c'est l'appelant qui porte la logique de validation, on peut utiliser l'Ioc.

[Kropernic]

Bonjour,
Discussion intéressante car je suis en train de mettre en place une politique d'exception pour nos futurs développements.

Concernant l'exemple de Kropernic,

Code :

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

1
2
3
4
 
If dlg.Nickname.ToLower = "channel" Then
      Throw New CustomException("Désolé mais ce pseudo n'est pas 
End If

je ne suis pas d'accord, simplement car selon moi le test de NickName doit être fait dans l’événement Validating du formulaire DlgConnection.
Si c'est l'appelant qui porte la logique de validation, on peut utiliser l'Ioc.

C'est pas faux ^^. Mais si je ne dis pas de bêtise, cela ne fait que déplacer la levée d'exception.

Après réflexion, c'est pas forcément vrai non plus ^^.
Le formulaire DlgConnection doit se charger de s'assurer que l'utilisateur encode un pseudo "correct". C'est-à-dire lisible et non choquant/injurieux. Autant le dire tout de suite, pour ce projet de chat qui me sert à tester WCF, je n'ai fait ni l'un l'autre mais si cela avait été un vrai projet, c'est à cela qu'il aurait servi. Après, je n'ai pas vraiment réfléchi sur le comment gérer le caractère "politiquement correct" du pseudo mais d'un point de vue fonctionnel, c'est la fonction de DlgConnection.

Ici dans l'exemple, le pseudo channel est refusé (je ne sais plus trop pourquoi j'ai voulu refusé ce pseudo mais disons qu'il s'agit du pseudo utilisé par le serveur pour communiquer sur le salon de chat) mais p-e que dans un autre chat, je vais vouloir réutiliser mon formulaire DlgConnection avec la même gestion du pseudo "politiquement correct". Sauf que pour cet autre programme, ce ne sera plus forcément le pseudo "channel" qui sera utiliser par le serveur.

Mais j'avoue que je cherche la petite bête.

[dkmix]

Ici dans l'exemple, le pseudo channel est refusé (je ne sais plus trop pourquoi j'ai voulu refusé ce pseudo mais disons qu'il s'agit du pseudo utilisé par le serveur pour communiquer sur le salon de chat) mais p-e que dans un autre chat, je vais vouloir réutiliser mon formulaire DlgConnection avec la même gestion du pseudo "politiquement correct". Sauf que pour cet autre programme, ce ne sera plus forcément le pseudo "channel" qui sera utiliser par le serveur.

Mais j'avoue que je cherche la petite bête.

D’où la possibilité d'utiliser l'IOC si c'est l'appelant du formulaire qui porte la logique de validation.

[Pol63]

C'est sûr que dans ce cas-là, je préfère de très loin l'écriture avec Exit Sub. Je n'ai cependant encore jamais dû écrire de telle procédure. Cependant, je suis de l'avis de Mac Twist quant à sa ressemblance avec le GoTo. C'est pour ça à la base que je ne l'aime pas.

pour info le compilateur transforme votre code avant de le transformer en msil et on peut voir avec un décompilateur que des fois il ajoute des goto
le goto n'a rien de sale, il est lié à la programmation des années 80/90 de laquelle on veut s'éloigner

après mon exemple vous fait peut etre peur, car il ressemble à exemple de tutoriel, totalement déconnecté de la réalité
mais en fait c'est un mode de programmation simple, on écrit une à une les questions qu'on doit se poser
autre exemple plus court sur l'envoie d'une commande sur un port

Code :

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

1
2
3
4
5
6
    Public Function EnvoieCommande(commande As String) As Boolean
        If commande = "" Then Throw New ArgumentNullException("commande")
        If etatdialogue = False Then Return False
        If uneAutreCommandeEnCours Then Return False
        stream.Write ...
    End Function

là on se pose les questions dans l'ordre, si pas connecté on ne peut pas envoyer la commande, s'il y a dejà autre chose en cours pareil etc...
sinon ca fait plein de if
en fait nous on décompose tout en petite fonction, on préfère return false plutot que throw, qu'on laisse pour des cas de bug (ici un développeur qui essaierait d'envoyer une commande sans la préciser, il a fait une erreur)
notre code fonctionne h24 et il peut y avoir des tas de cas où une erreur se passe dans un morceau de code (comme un simple deadlock sql ou une erreur de com) donc chaque morceau est autonome et on test le retour des fonctions si c'est pas bon on mets un message d'erreur et on retentera au prochain tour (ou suite à autre tentative demandée par l'ui)
et dans nos fonctions on a un byref message as string pour les soucis
ca n'empeche pas de mettre nothing dans le paramètre et de ne pas tester la valeur de retour si dans un cas on s'en fout

[rv26t]

Bonjour,

Voici un tuto intéressant sur le sujet : Comprendre la philosophie des exceptions sous .NET.

[mactwist69]

Suis assez d'accord sur le principe de se poser les questions au fur et à mesure, ça fait même gagner du temps.

Cela dit, pour ce genre de procédure, si il y a trop d'Exit Sub, alors j'utiliserai plutôt une fonction qui va tout tester et retourner True ou False.

Et de temps en temps,dans une procédure, Exit Sub, exceptionnellement.

[Sankasssss]

Désolé de ne pas avoir suivi en direct le sujet mais je suis fortement occupé pour le moment. Les journée sont malheureusement très courte en été.

(pour info, je suis l'autre dev dont sankass parle dans son intro)

De fait, et c'est à ta demande que j'ai ouvert le sujet.

Voici un tuto intéressant sur le sujet : Comprendre la philosophie des exceptions sous .NET.

Merci pour cet excellent article, en combinaison avec les avis de cette discussion, cela conforte va vision des exceptions et de leurs utilisations.

J'utilise l'évènement d'application UnhandeldException pour gérer "en bout de course" les exceptions qui ne le sont pas par l'application. Je récupère leur message, stacktrace et inner exception et je fourre tout dans une DB prévue à cette effet et j'affiche un message générique à l'utilisateur.

C'est effectivement ce que je fais depuis quelque mois afin de pouvoir nous envoyer une notification par email des erreurs qui ne sont pas interceptée et dans cette nouvelle philosophie, je n'intercepte quasiment plus d'exception dans mes sub.

Bon je suis chaud (il faut dire, j'ai travaillé mon sujet). Les exceptions, il y a plein de manière de voir les choses...

Je ne recopie pas tout ton sujet pour la lisibilité du message mais comme dis dans l'article :

Ne jamais déclencher une exception générique.

je pense que générer une exception de type Exception n'est pas la meilleur chose vu les diverses exceptions qu'il existe. (Je dois avouer le faire de temps en temps pour gagner du temps mais ce n'est pas dans la philosophie du code propre)

Mes deux sous à ce sujet :

L'exception est parfaite pour gérer les cas de figure exceptionnels. Cela masque certes le flux de contrôle pour ces cas exceptionnels mais en contrepartie la lisibilité du flux de contrôle ordinaire en est grandement simplifiée. N'importe qui ayant eu à faire remonter des codes d'erreurs sur douze niveaux pourra témoigner du bénéfice obtenu.

C'est une bonne pratique et ça n'a absolument rien de sale ou de bâclé ! Quant au coût sur les performances, il est de quelques microsecondes ce qui est rarement problématique dans les cas véritablement exceptionnels (ce qui est le cas de toute erreur nécessitant une action utilisateur).


En revanche j'ai beaucoup plus de mal avec l'idée de gérer l'UI via des exceptions. Ça me semble complètement tordu, ne serait-ce que parce que la bonne réponse est souvent plus complexe qu'une boîte de dialogue. Par ailleurs soit on est dans le code UI et alors c'est à lui d'afficher directement l'erreur comme il convient, soit on est dans une couche métier et alors un message d'erreur utilisateur n'y a pas sa place.

La bonne solution dans ce dernier cas est soit de passer au code métier une interface (disons "IErrorHandler") avec les méthodes adaptées (quitte à lever après une exception non-utilisateur pour remonter dans le code), soit de lever une exception générale sans message particulier et ce sera au code UI de la traiter et de décider quoi en faire et quel message éventuellement afficher.

Je suis complètement d'accord avec ta façon de penser. Je n'ai jamais dit qu'il ne fallait pas utiliser d'exception bien loin de là et c'est effectivement très bien pour remonter des informations et couper le traitement sur plusieurs niveaux. Bête exemple, un programme d'impression de courriers génère une exception quand la ligne de la base de donnée n'est pas cohérente avec l'état du document à imprimer. En théorie ceci n'est jamais censé arriver sauf si il existe un état incohérent entre la base de donnée et l'application d'où il ne faut surtout pas pouvoir imprimer ce courrier mais remonter l'information afin que ceci soit corrigé.

je pense qu'on a fait le tour sur ce qu'il y avait à dire sur les exceptions, donc un peu de hors sujet ne fait pas de mal ^^
concernant les exit sub...

Lol, tout s'explique : Le Exit Sub prennent effectivement tout leurs sens Si et seulement si on est interdit de faire plus de 2 If imbriqués...

Ce n'est pas nécessairement hors sujet vu que c'est abordé dès les premiers messages
Je suis la aussi d'accord avec cette manière de faire. Tant que l'exit sub est au début du code je le préfère 100 fois à un if imbriqué. Je le trouve bien plus lisible pour les raisons données par Pol63.
Par contre si je tombe sur une sub de 100 lignes (déjà la je râle) qui contient un exit sub en plein milieu c'est une autre histoire et je peste grandement (Même si j'ai du le faire à mes débuts...)

Cependant, je suis de l'avis de Mac Twist quant à sa ressemblance avec le GoTo.

et faire un throw new MonException pour l'intercepter 10 lignes plus loin ça ressemble pas à un goto ?


Pour terminer, je dirais que je trouve que la programmation par exception quand elle n'est pas exceptionnel casse tout simplement le flux normal du code. Comme expliqué dans l'article, bien sûr qu'il faut lever une exception si les paramètre d'entrée d'une méthode publique ne correspondent pas à ce que l'on attend MAIS il faut aussi tout faire pour tester ces paramètres avant de les donner à la méthode afin de ne pas déclencher d'erreur qui doivent rester exceptionnel et pour moi un utilisateur qui rentre des mauvaises informations de connexion n'est pas exceptionnel ^^

[mactwist69]

et faire un throw new MonException pour l'intercepter 10 lignes plus loin ça ressemble pas à un goto ?

Pas tout à fait.

Exit sub en plein milieu d'un procédure Stop le flux normal, sous entendu il faut s'assurer que stopper une procédure en plein milieu rentre dans le flux normal... Ce que je trouve quand même spécial !

Alors que... Un Throw new MonException, si je fais une image soit on prends l'autoroute et tout se passe bien (on descends et on remonte). Si il y a un accident, on remonte en empruntant la bande d'arrêt d'urgence. On passe d'un flux normal à un flux de secours qui peut être tracé et anticipé.
En plus de cela il remonte de l'information.

Certes au moment où on va dans le catch, il y a une sorte de Goto... Mais bon, il faut bien qu'il y ait à un moment donné un pont pour relier les deux flux.

[Kropernic]

Ce n'est pas nécessairement hors sujet vu que c'est abordé dès les premiers messages
Je suis la aussi d'accord avec cette manière de faire. Tant que l'exit sub est au début du code je le préfère 100 fois à un if imbriqué. Je le trouve bien plus lisible pour les raisons données par Pol63.
Par contre si je tombe sur une sub de 100 lignes (déjà la je râle) qui contient un exit sub en plein milieu c'est une autre histoire et je peste grandement (Même si j'ai du le faire à mes débuts...)

Si ce Exit Sub suit un MessageBox.Show, tu pestes moins s'il y a un Throw New CustomException à la place avec le MessageBox.Show dans le Catch ?

[Sankasssss]

Mais il n'y a pas besoin d'exit sub :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
        Try
            If Chose > 0 Then
                If machin = 0 Then
                    If truc > -1 And bazar <> 1684 Then
                        ' ...
 
                    ElseIf machin > -1 Then
                        ' ...
                        If truc > 0 Then
                            '...
                        Else
                            Throw New ApplicationException("Il y a un problème pour le chargement de tous les calculs - comparaisonGRH ligne 198") ' Bon c'est la ligne 502 mais c'est pas grave...
                        End If
                    Else
                        Throw New ApplicationException("Vous n'appartenez à aucun groupe autorisé à accéder à ce programme.")
                    End If
                Else
                    Throw New ApplicationException("Il y a un problème dans cAutoritésDeValidation.DetecterInfosLdap() - comparaisonGRH 204")
                End If
            Else
                Throw New ApplicationException("Vous ne disposez pas des autorités requises, veuillez vous adresser à votre administrateur.")
            End If
        Catch ex As Exception
            MessageBox.Show(ex.ToString, "MU0127VB - Comparaison GRH fichier Sepa et fichier log", MessageBoxButtons.OK, MessageBoxIcon.Error)
            Application.Exit()
        End Try

vs

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
            If Chose > 0 Then
                If machin = 0 Then
                    If truc > -1 And bazar <> 1684 Then
                        ' ...
 
                    ElseIf machin > -1 Then
                        ' ...
                        If truc > 0 Then
                            '...
                        Else
                            Throw New ApplicationException("Il y a un problème pour le chargement de tous les calculs - comparaisonGRH ligne 198") ' Bon c'est la ligne 502 mais c'est pas grave...
                        End If
                    Else
                        MessageBox.Show("Vous n'appartenez à aucun groupe autorisé à accéder à ce programme.", "Information", MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
                    End If
                Else
                    Throw New ApplicationException("Il y a un problème dans cAutoritésDeValidation.DetecterInfosLdap() - comparaisonGRH 204")
                End If
            Else
                MessageBox.Show("Vous ne disposez pas des autorités requises, veuillez vous adresser à votre administrateur.", "Information", MessageBoxButtons.OK, MessageBoxIcon.Exclamation)
            End If

Le deuxième est quand même mieux non?

[Kropernic]

Dans ce cas-ci, oui, le 2e cas est mieux.

Mais de base, je n'aime pas tous ces if imbriqués, j'aurais probablement codé cela autrement.

Si j'ai la possibilité de ne pas en utilisé, je le fais. Quitte à utilisé une exception ^^.

Je trouve que les if diminuent la lisibilité du code. Bon, 1 if, ça va hein. Mais à partir de 2, ça peux vite devenir le bordel. C'est pas pour rien qu'il y a des endroits où on ne peut pas imbriqués plus de 2 niveaux de if ^^.

[Sankasssss]

j'aurais probablement codé cela autrement.

ça c'est sûr, aucun doute là dessus !!!