Ce cours est visible gratuitement en ligne.

Ce cours existe en livre papier.

Ce cours existe en eBook.

J'ai tout compris !
Apprenez à programmer en VB .NET

Apprenez à programmer en VB .NET

Mis à jour le lundi 24 juin 2013
  • 4 semaines
  • Facile

Votre superbe IDE Visual Basic Express 2010, ou Visual Studio faute de mieux, permet facilement de retrouver et de gérer les erreurs. Il indique la ligne ayant provoqué l'erreur, l'explication de l'erreur (en français) et parfois comment la résoudre. Mais pour ce qui est des autres erreurs ? Les erreurs qui ne sont pas liées à notre programme ? Ras le bol de faire 50 if pour vérifier si la base de données à laquelle on veut accéder est bien là, voir si la table est bien présente, voir si la requête a bien fonctionné, etc.

Nous allons donc utiliser un autre point de vue pour gérer ces passages : la gestion d'erreur. Vous allez découvrir le… Try !

Découvrons le Try

Le mot « try » est le mot anglais pour « essayer ». Le programme va donc essayer les lignes de code que vous définirez, si une erreur se présente dedans, il va automatiquement dans une partie de votre programme, et l'erreur ne vous saute pas aux yeux comme si vous veniez de tuer quelqu'un.

Voici sa syntaxe :

Try
    'Code à exécuter
End Try

Donc, ce code exécutera ce qu'il y a entre le Try et son End Try ; si une erreur se produit, il sort du Try. Pour le moment, pas compliqué donc.

Gros malin, ça ne m'avance pas ! Une erreur et je me retrouve à la fin de mon programme direct !

D'où l'intérêt d'utiliser ce Try dans chaque fonction ! À chaque début de fonction, vous mettez votre Try, et à la fin, votre End Try ! Si la fonction échoue, elle sera ignorée, c'est tout !

Et alors ? Une fois de retour où la fonction a été appelée, si je n'ai pas de valeur, ça va également planter !

Hum ! c'est pas faux tout ça, passons alors au Finally.

Finally

Dans le Try nous avons d'autres instructions pour nous aider : tout d'abord le Finally.

Je vous ai dit que si une erreur se produisait dans le Try il sautait tout. Oui, mais dans une fonction ça va faire quoi ? S'il saute tout, même le retour de la fonction ?

Function Erreur() as integer
    Try
       'Code pas très sûr
    Finally
       Return 0
    End Try
End Function

Et voilà la solution : si une erreur se produit, paf ! il saute dans le Finally et il retourne une valeur quoi qu'il arrive (même si aucune erreur n'est à déclarer) !

Donc si vous avez suivi depuis le début, vous mettez un Return d'office dans le Finally et un Return dans le déroulement normal de la fonction. Si aucune erreur n'est à déplorer, le Return de votre fonction aura la priorité et rendra l'autre inopérant.

Si c'est une demande de connection à un site web, que le site en question ne trouve pas la base de données, on aura une erreur, mais l'utilisateur sera bloqué… Que faire ?

On va les renvoyer.

Catch, throw

Notre salut : le Catch !

Se place comme le Finally, entre le Try et son End Try, mais avant le Finally.

Le catch va nous permettre de récupérer l'erreur dans une variable de type Exception :

Catch ex As Exception

… que j'appelle ici ex.

Ensuite je peux récupérer cette variable et m'en servir pour afficher l'erreur par exemple :

Private Sub BT_ENVOI_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BT_ENVOI.Click
        'On essaie
        Try

        Dim MonTxt As Integer

        MonTxt = Me.TXT_IN.Text
            Me.LBL_OUT.Text = MonTxt

            'Si erreur, on l'affiche
        Catch ex As Exception
            MsgBox(ex.ToString)
        End Try

    End Sub

Je l'affiche donc dans une MsgBox. Le résultat se trouve à la figure suivante.

Le résultat du code précédent
Le résultat du code précédent

Vous allez me dire que l'utilisateur lambda n'en a rien à faire de notre message d'erreur, que lui, il veut que ça marche !

Mais l'affichage n'est pas forcément nécessaire : on peut récupérer cette variable, l'écrire dans un fichier log, les possibilités sont multiples. Ou alors on la renvoie.

Pardon ?

Oui, on la renvoie à l'étage du dessus : si c'est dans une fonction que l'erreur se produit :

Private Sub BT_ENVOI_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BT_ENVOI.Click
        Try
            Bouton()
        Catch ex As Exception
            MsgBox(ex.ToString)
        End Try
    End Sub

    Private Sub Bouton()
        'On essaie
        Try

            Dim MonTxt As Integer

            MonTxt = Me.TXT_IN.Text
            Me.LBL_OUT.Text = MonTxt

            'Si erreur, on la renvoie à la fonction qui l'a appelée
        Catch ex As Exception
            Throw ex
        End Try
    End Sub

Donc, ici, j'envoie à l'instance du dessus l'erreur, une fois de retour dans cette fonction, le programme voit qu'une erreur s'est produite en amont, elle rentre elle-même dans son Catch.

Inutile, me direz-vous ? Pas forcément, pourquoi ne pas utiliser ce Try… Catch avec son Throw dans tous vos accès aux bases de données, et un Try… Catch avec une gestion spécifique d'erreur dans la fonction qui les appelle toutes ?

Une seule gestion d'erreur pour vérifier des dizaines de requêtes, ce n'est pas magnifique ? :)

  • On commence par le bloc Try.

  • Si une erreur se produit dans le bloc Try, le bloc Catch est alors exécuté.

  • Quoi qu'il arrive, le bloc Finally sera exécuté.

Exemple de certificat de réussite
Exemple de certificat de réussite