Discussion :

[Laurent Dardenne]

Salut,
dans le code suivant je code une régle de gestion :

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
private byte mAge;
/// Age d'une personne
public byte Age
{
  get
  {
    return (mAge);
  }
  set
 {
    if ((value==0) || (value<=AgeMaximum))
      mAge = value;
    else throw new AgeIncorrectException();
 }
}

Selon certains (*) cette approche, déclencher une exception dans un accesseur, n'est pas recommandé.

J'aimerais donc savoir s'il existe une autre solution que celle-ci pour coder une régle de gestion sur une propriété ?

[smyley]

Selon certains (*) cette approche, déclencher une exception dans un accesseur, n'est pas recommandé.

Ben vu qu'il n'y a pas 36 000 façons de définir une variable, il devrait préférer un truc du genre

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
 
byte age = 0;
public byte Age
{
  get { return age; }
}
 
public virtual bool DéfinirAge(byte n_age)
{
  if(n_age >= 0 && n_age <= AgeMaximum)
  {
    age = n_age;
    return true;
  }
  else
    return false;
}

(ceci dit, je fait tout le temps des exceptions dans les accesseurs et bon )

[Kaidan]

Bonjour,

Dans le Framework .NET, y'a beaucoup d'accesseurs qui retournent des exceptions, je vois pas vraiment où est le problème. C'est clair qu'il vaut mieux toujours vérifier les variables dans le code appellant, mais ce n'est pas forcément possible quand on écrit des bibliothèque et l'exception reste le mécanisme principal pour remonter une erreur.

[Laurent Dardenne]

ceci dit, je fait tout le temps des exceptions dans les accesseurs

C'est vrai que cette approche facilite le codage. De plus cette régle de développement me semble difficile à respecter

[smyley]

...

Je suis entièrement d'accord avec toi mais en fait j'ai pas eu la foi de lire le document cité par Laurent ... ce serai bien s'il nous citait le passage dans lequel il est question de cette "proscription"

[Laurent Dardenne]

je vois pas vraiment où est le problème.

Débutant sous C# j'essaie de suivre des régles de développement ou tout du moins de prendre de bonnes habitudes.
Les autres régles que j'ai pu trouvées dans l'ouvrage indiqué ne me posent pas de pb particulier.

[smyley]

Débutant sous C#

ça fait bizarre, avant c'était Delphi non ?

j'essaie de suivre des régles de développement ou tout du moins de prendre de bonnes habitudes.
Les autres régles que j'ai pu trouvées dans l'ouvrage indiqué ne me posent pas de pb particulier.

Non mais en fait une des principales règles avec les exceptions c'est qu'il ne faut pas en abuser ou s'en servir quand c'est pas franchement nécéssaire car le procéssus de lancement d'une exception est gourmand en ressources et que de plus, le code résultant d'une utilisation massive des exceptions sera probablement obscur et difficil à maintenir. Cependant lorsque c'est pour signaler une erreur de valeur ( même si on vérifie avant la valeur entrée par l'utilisateur ) les exceptions sont très efficaces ( même dans un accesseur ). Au moin on est sur de cours circuiter toute donnée invalide ( par exemple dans ton cas, il n'y aura aucun moyen de se balader avec des ages négatifs ) et, pour moi, mettre la vérification dans l'accesseur est une méthode simple et élégante, en éssayant de faire autre chose on se complique la vie .

[SirJulio]

Salut,

je n'ai pas trouvé le passage en question dans le livre (pas mal btw), mais je pense que ce qu'ils ont voulu dire, c'est que, theoriquement, une propriété 'simple' (le cas general) n'est pas sensé lever une exception, contrairement à une methode. Cependant, si cette levée est indiquée, (par un comment intellisense par exemple, comme le fait le framework), je ne vois pas ou est le probleme, c'est meme preferable, AMHA, de lever l'exception à l'initialisation de la variable en question, plutot que de lancer une InvalidOperationException, par exemple, plus tard (qui perdra de son sens).

[Laurent Dardenne]

ce serai bien s'il nous citait le passage dans lequel il est question de cette "proscription"

page 69

Code :

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

1
2
 
14. Throw the InvalidOperationException exception if a call to a property set accessor or method is not appropriate given the object's current state.

Voir aussi le livre "Pratique de .NET 2 et C#2" de Patrick Smacchia, page 409
"Il est conseillé de ne pas lancer d'exception à partir d'un accesseur, à moins quelle soit rattrapée dans l'accesseur même. En effet syntaxiquement le client n'a pas nécessairement conscience d'appeler un accesseur lors de l'accés à une propriété. Le client peut donc être surpris par une exception."

ça fait bizarre, avant c'était Delphi non ?

Oui mais je ne suis pas trop perdu
Et puis je continuerai d'utiliser Delphi sous Win32.

en essayant de faire autre chose on se complique la vie

C'est pas mon objectif. J'essaie de trouver une implémentation simple pour cette recommendation.

[smyley]

"Il est conseillé de ne pas lancer d'exception à partir d'un accesseur, à moins quelle soit rattrapée dans l'accesseur même. En effet syntaxiquement le client n'a pas nécessairement conscience d'appeler un accesseur lors de l'accés à une propriété. Le client peut donc être surpris par une exception.

Je suis pas vraiment d'accord avec sa manière de voir la chose. Il vaudrait donc mieux laisser le client mettre n'importe quoi comme valeur et ne l'avertir que lorsqu'il croit déjà que tout est bon et qu'il attend juste de terminer son opération ?
Si c'est un GUI, il faut dire au client "non, ce que vous faites n'est pas autorisé" et alors l'empécher d'assigner une mauvaise valeur. Si c'est un programmeur qui accède à la lib, il vaut mieux lui signaler direct que la valeur n'est pas valide, au moin il pourra identifier plus facillement la source du problème.
D'ailleurs :

c'est meme preferable, AMHA, de lever l'exception à l'initialisation de la variable en question, plutot que de lancer une InvalidOperationException, par exemple, plus tard (qui perdra de son sens).

On est sur la même longueur d'onde
Par contre c'est vrai que dans le cas d'une exception, il est préférable de signaler dans la documention que cette propriété peut lever tel exception. D'ailleurs, Java est plus strict sur ce point car il oblige les programmeurs à expliciter toutes les exceptions pouvant être levée dans leur code

[SirJulio]

Amha, que l'on ne veuille pas lancer d'exception depuis un get, c'est tout à fait comprehensible, mais quand tu changes la valeur d'un champ par un set, et que ce champ peut devenir invalide, autant lancer l'exception le plus tot possible pour essayer de la resoudre, plutot que d'attendre qu'une methode se rende compte (bien apres) que le champ est invalide et que tu ne puisses plus rattraper le coup (ou du moins plus difficielement).

En documentant l'exception, je pense que ca reste une utilisation 'raisonnable'

[Laurent Dardenne]

Il vaudrait donc mieux laisser le client mettre n'importe quoi comme valeur et ne l'avertir que lorsqu'il croit déjà que tout est bon et qu'il attend juste de terminer son opération ?

PS ne dit pas ça, il émet un conseil mais ne donne aucune information pour le mettre en oeuvre.
J'ai hésité avant de poster sur ce sujet mais après qq jours de réflexion je n'ai pas trouvé de solution pour suivre son conseil.

[smyley]

lol, je sais pas, mais son conseil me parait bizarre quand même, "vaut mieux rien dire sur les erreurs pour pas faire peur" ...

[Thomas Lebrun]

L'avantage des accesseurs, c'est qu'ils permettent justement de faire des tests lorsqu'on les appelle. Si on peut faire des tests (comme tu le fait), rien n'est anormal dans le fait de lancer des exceptions dans ces accesseurs

[oyigit]

Personnellement je ne me permettrai pas de lancer une exception depuis une propriété. Je bosse depuis plus d'un an dans un SSII (je développe en C#) et sur chacune de nos applications nous partageons les couches de dév (Transport, Business, DAO) pour ce qui en ont entendu parlé. La couche de transport ne gère pas les exceptions, et n'en génèrent pas non plus. Tous les points d'entrée à l'application sont centralisé dans la couche Business. Ainsi toute interaction avec l'application, qu'elle soit interne (Site Web, Client lourd) ou proviennent d'applicaiton tierce (par le biais de Web Service, d'appel HTTP ou tout autre protocole) passe d'abord par la couche Business (Service en français). Comme il s'agit du point d'entrée pour tous les points d'entrée, c'est elle qui gère et génère les exceptions. Le traitement n'est fait qu'une seule fois pour toute l'application.

[Laurent Dardenne]

rien n'est anormal dans le fait de lancer des exceptions dans ces accesseurs

On est d'accord la dessus.

Le traitement n'est fait qu'une seule fois pour toute l'application.

Effectivement il y avait aussi cette problèmatique dans mes réflexions.

Je viens de consulter l'ouvrage ".NET" Dick Lantim et il propose, pg 154, un début de réflexion autour d'un attribut personnalisé, qui porterai la régle de gestion, couplé à un proxy+ IMessageSink

Donc ce que je recherche est plus du domaine de la programmation par contrainte que je ne connais pas. J'ai regardé rapidement F# qui lui propose se type d'approche, tout comme Chrome, enfin en partie il me semble.

J'ai peut être une autre piste sur IDesign mais là je manque de temps pour creuser le sujet.

Je vais donc faire au plus simple en attendant une hypothétique implémentation des contraintes en C# 4.0 issues de F# ...

Je vous remerci pour vos réponses.