Exceptions, quand les utiliser

Bonjour

Tout est dans le titre.

Exemple concret pour lequel je me pose la question :

J'ai une List de UserControl (ils représentent un chemin affichés sur une carte).
Dans la classe qui contient ma liste j'ai encore un entier qui contient l'indice du control actuellement actif/sélectionné (activeControl) et une méthode qui me permet de récupérer le control actif (getActiveControl).
Il peut arriver qu'aucun control ne soit sélectionné (activeControl = -1). Or dans ces cas-là, si je fait appel à getActiveControl j'obtiens évidemment une ArgumentOutOfRangeException.

Ma question : que dois-je faire ? Traiter cette exception ou vérifier que activeControl != -1 avant de récupérer mon control ? J'ai vu sur certains sites que les exceptions doivent être utilisée dans des cas inattendus/non prévus. Ce n'est pas vraiment le cas chez moi puisque le fait qu'aucun control ne soit sélectionné est un cas "normal".

Utilises-tu le framework 1.1 ? ou une version ultérieure ?

La règle de gestion "si aucun élément n'est sélectionné alors je vais positionner l'index à -1" n'est pas très naturelle (du point de vue Orienté Objet), même si elle est souvent usitée dans nos projets.

Est ce que la règle suivante te semble naturelle ? "si le libellé NomDeJeuneFille n'est pas renseigné, alors mettre la valeur 'yenapascarcestpasunefille' en base de données" :)

Du coup, si tu as la possibilité de rendre les éléments à nullable, il me semble plus logique de transformer ton champs :

Code:

---

1 2	private int? indexActiveControl;

---

Maintenant pour ta méthode getActiveControl, dans ton code, si l'index est à null, renvoie alors un objet null, sinon, renvoie le bon objet instancié.

Il me semble aussi non naturel d'intercepter une exception s'il n'y aucun composant. Prends pour exemple ces élements assez familier du framework ASP.NET :

Code:

---

1 2 3 4 5 6

Panel monpanneau = new Panel(); if (monpanneau.Controls == null) Response.Write("Le panneau est vide"); else Response.Write("Le panneau contient " + monpanneau.Controls.Count + " éléments");

---

A toi de vérifier l'existence de l'objet lors de l'appel de la méthode, et ce sans passer par une gestion des exceptions.

Les exceptions servent à gérer des éléments imprévus, enfin.. pas si imprévus que ça car on s'y attends quand même un peu :

"Mon programme ouvre un fichier en écriture et rajoute des données dedans".

N'est pas une exception : on veut connaître le nombre de lignes à l'ouverture du fichier, si le fichier existe mais est vide, on le prévoit par des tests préliminaires.

Est une exception : on ouvre le fichier en lecture, mais une autre application (ah sacré chef qui a ouvert le fichier avec Word mais qui ne l'a pas fermé) l'a déjà ouvert.

Version 2
Langage C#

Code:

---

private int? indexActiveControl;

---

Ah, ben j'ai appris quelque chose aujourd'hui. Je me demandais comment avoir un int null.


Donc, en reprenant mon cas, il vaut mieux faire

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public myControl getActiveControl() { if(activeControl == null) { return null; } else { return controlsList[activeControl]; } }

---

que

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public myControl getActiveControl() { try { return controlsList[activeControl]; } catch (Exception e) { return null; } }

---

?

Je ne suis pas un expert dans le domaine, j'ignore quelle méthode utilise le plus de ressource processeur : l'utilisation d'un test ou l'utilisation d'un bloc try catch.

En tout cas, jamais je n'utilise le bloc try catch quand il peut être substitué par un test.

Surtout qu'en marquant :

Code:

---

1 2 3 4 5 6 7 8 9

try { return controlsList[activeControl]; } catch (Exception e) { return null; }

---

tu n'interceptes pas la véritable exception si controlsList n'a jamais été instancié !

Renomme aussi activeControl en indexActiveControl, vu que c'est un index :) activeControl ça sonne comme une instance d'objet UserControl.

Citation:

---

Envoyé par JuTs

Donc, en reprenant mon cas, il vaut mieux faire

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public myControl getActiveControl() { if(activeControl == null) { return null; } else { return controlsList[activeControl]; } }

---

---

Oui.

Si tu peux faire un test pour éviter une exception, fais le test, parce que ça n'a rien d'exceptionnel. Tu sais à quoi t'attendre.

Les exceptions, c'est pour quand tu ne sais pas gérer une erreur là où tu te trouves. Tu balances une exception et tu laisses le code appelant se débrouiller. Peut-être qu'il en saura plus.

Si tu sais quoi faire dans un cas qui balancerait une exception, fais-le.

Inconvénient du code ci-dessus par contre, le code appelant doit traiter le cas où la valeur de retour est nulle. Mais pareil, si c'est un cas qui peut arriver, ça n'a rien d'exceptionnel. Donc le code n'a qu'à le gérer.

ok, merci

A noter que pour des histoires d'optimisation, on peut se contenter d'un index=-1.

le coup du nom de jeune fille ne semble pas naturel, parce que "yenapasparcecestpasunefemmemariee" est une valeur qui appartient à l'ensemble des valeurs valides pour ce champ.

index == -1, -1 n'est pas valide, c'est à dire qu'il n'a aucun sens : le -1ième élément d'un tableau.... -_-... à la limite en C/C++ avec du code crade pourquoi pas... lol

Enfin bref, on peut donner un sens à ce -1, et dans ce cas la valeur ayant un sens unique (pas de collisions avec un autre sens quoi), tu sais la traiter, donc c'est correct.

les types primitifs nullables, genre int? demandent plus de ressources.
Quand on écrit : int? a; il faut comprendre qu'on a écrit : Nullable<int> a;