Discussion :

[Nico28]

Bonjour à tous,

Dans une méthode qui retourne un booléen, j'utilise du Try/Catch

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
 
private bool MaFonction()
{
    try
    {
        ...
        if(...erreur....)
            return false;
 
        ...
        return true;
    }
    catch(Exception ex)
    {
        return false;
    }
}

Mais je me pose la question suivante :
ma technique de sortie par "return" est-elle correcte (techniquement et éthiquement) ou il vaudraiat mieux :

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
 
private bool MaFonction()
{
    bool blRetour = true;
 
    try
    {       
        ...
        blRetour = true;
    }
    catch(Exception ex)
    {
        blRetour = false;
    }
 
    return blRetour;
}

mais dans ce cas, comment gérer :

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
private bool MaFonction()
{
    try
    {
        ...
        if(...erreur....)
            return false;

        ...
        return true;
    }
    catch(Exception ex)
    {
        return false;
    }
}

un bon vieux Goto qi nous envoie après le catch ??


Merci de vos idées.

[Invité]

Bonjour,

Tout d'abord, il me semble que ce post ne se trouve pas dans le bon sujet, je l'aurais mis plutôt dans "C#".

A mon avis, d'une manière générale, s'il s'agit d'une petite fonction, la 1ère syntaxe ne pose pas de problème. En revanche, si tu as fait une fonction avec beaucoup de lignes, ce n'est pas trop recommandé pour la lisibilité. C'est la raison principale pour laquelle les profs ne voulaient surtout pas voir ça dans les programmes qu'on leur rendait dans les TPs etc. C'est donc plus une question de lisibilité et de maintenabilité que d'étique

Cela dit, il y a une manière de travailler avec dotnet qui est assez répandue, notamment chez Microsoft : on fait des tests critiques au début d'une fonction, et si ces tests sont négatifs, on lance une exception.
Le plus courant est le test d'une variable qu'on ne veut surtout pas voir null comme par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
int MaFonction(string variableQuiNeDoitPasEtreNull)
{
   int unResultat=0;
   if (null==variableQuiNeDoitPasEtreNull)
       throw new ArgumentNullException("variableQuiNeDoitPasEtreNull");
 
   //Suite du code...
 
   return unResultat;
}

Tout dépend donc des conventions qu'il peut y avoir dans l'entreprise, de l'école, ou même du groupe qui travaille sur le projet...

[pascalCH]

A mon sens, une bonne procédure à un point d'entrée et un point de sortie.
Donc une structure try..catch avec une variable locale pour le résultat permet d'avoir une structure claire.

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
 
 public Boolean MaFonction(int unParametre)
 {
     Boolean result;
     try 
     {
        unParametre = 5 / unParametre;
        if (unParametre > 5)
            result = true;
         else
            result = false;
     }
     catch (Exception)
     {
         result = false;
     }
     return result;
}

[Nico28]

Je trouve effectivement que c'est "mieux", avec 1 point d'entrée et 1 point de sortie. Donc pour les erreurs que je gère moi même, je lève une exception (que je créé moi même) qui me renvoie vers le bloc Catch de la fin.