Discussion :

[progfou]

Bonjour tout le monde !

J'ai un code qui a souvent le même style de gestion des erreurs... Exemple:

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
int maFonction()
{
  int errCode = 0;
  if (uncas)
  {
    //du code, avec une gestion d'erreur
    return errCode;
  }
  if (unautreTruc)
  {
    //du code encore, avec une gestion d'erreur
    return errCode;
  }
}

Vous avez compris, j'aimerais éviter les sorties multiples, avec les return au milieu du code, mais également ne pas avoir à faire:

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
int maFonction()
{
  int errCode = 0;
  if (uncas)
  {
    //du code, avec une gestion d'erreur
    return errCode;
  }
  if ((unautreTruc) && (errCode == 0))
  {
    //du code encore, avec une gestion d'erreur
    return errCode;
  }
}

Y a-t-il un Design Pattern qui réponde à ce genre de problème ?
Merci d'avance !

[hed62]

Introduire un pattern pour ce genre de chose risque d'être lourd.

Si tu peux, emploie les Exceptions, mais cela revient au même...

Regarde à la limite Chaine de responsabilité, mais c'est lourd pour ce genre de problématique (une classe par cas à traiter) et au final ce sera moins lisible.

Qu'est ce qui te gene dans les sorties multiples exactement ?

[progfou]

Le nombre cyclomatique (complexité McCabe).
Dans le système en question, on a des limites à respecter, et les sorties multiples font exploser ce nombre...

Si pas un DP, peut-être une autre solution.
Les exceptions c'est compliqué car c'est un système Symbian (donc avec son propre gestionnaire d'exception).

[hed62]

(donc avec son propre gestionnaire d'exception).

Il faut peut être creuser de ce coté ?

Si vraiment les sorties multiples te gênent, Chaine de Responsabilité peut potentiellement t'aider, mais là, au niveau de la complexité ...

[progfou]

En gros, si personne ne récupère l'exception à un niveau plus élevé, elle sert à rien, et risque de planter le système... Ca introduit des risques.

Chaine de responsabilité risque effectivement d'être le marteau pour tuer la mouche.

Il n'existe aucune solution de conception à ce problème ?

[hed62]

En gros, si personne ne récupère l'exception à un niveau plus élevé, elle sert à rien, et risque de planter le système... Ca introduit des risques.

C'est le propre des Exceptions.

Pour moi, il n'y a pas de solution de conception à ce problème, car c'est un soucis d'implémentation, pas de conception.

Car, de toutes manières :
- tu vas devoir faire ton switch.
- tu vas devoir traiter les erreurs une par une.

Peut être une piste :

f1 et f2 sont des fonctions qui effectue tes controles :

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
 
int ma_fonction(p1,p2,p3)
{
  int erreur;
  Liste liste = new Liste();
  liste.Add(f1, new object[]{p1});
  liste.Add(f2, new object[]{p2,p3});
 
  return liste.traiter();
}
 
class Liste
{
  // constructeur
  int traiter() 
  {
    int erreur = 0;
    foreach(fonction in liste_interne)
    {
      erreur = fonction(params);
      if(erreur!=0) 
        return erreur;
    }
  }
}

Ce n'est qu'une piste en pseudo code bien sur... Ca vaut ce que ca vaut

[Nip]

Le nombre cyclomatique (complexité McCabe).
Dans le système en question, on a des limites à respecter, et les sorties multiples font exploser ce nombre...

Peut etre, mais en contrepartie le niveau d'imbrication est beaucoup moins eleve (Nesting Depth) puisque de 1, et ca aussi, ca rentre aussi dans le calcul de la complexite, et c'est surtout super lisible et facilement testable.
Je trouve que c'est un bon compromis .

[koala01]

Salut,

Ce que tu peux déjà faire, si uncas et unautreTruc sont compatibles avec les tests à choix multiples, c'est de te diriger vers cette solution...

Cela conduit vers un code proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
err <==0
SELON variable
    CAS uncas
        traitement
        err<== 1
    FIN CAS
    CAS unautreTruc
        traitement
    FIN CAS
    CAS defaut
        traitement si ce n'est ni uncas ni unautreTruc
FIN SELON
renvoie err

Cela ne produira pas moins de tests au final, mais tu te retrouve avec le SISE auquel tu semble tellement tenir

Evidemment, si les tests portent sur des variables différentes, il devient difficile d'utiliser les tests à choix multiples

[EDIT]A titre personnel, je me dis que la chaine de responsabilité risque d'être encore plus lourde à l'utilisation que le fait d'avoir des retours multiples

[hed62]

je me dis que la chaine de responsabilité risque d'être encore plus lourde

Ah oui tout à fait !