Bien programmer une classe avec sa gestion d'erreur

bonjour,
j'ai une question simple sur l'utilisation de la gestion d'erreur en .NET.

Donc j'ai une classe Client, ma classe lit un client en particulier dans la base suivant un ID.

public class Client
private _Nom as String

'Encapsulation.......

pour lire le nom contenu dans le dataset qui a ete rempli par une requete du genre "SELECT Nom FROM Client WHERE Id=1", vaut il mieux faire

try
Nom = MyDataSet.Table(0).Rows(0).item("Nom").ToString
catch
Nom = String.empty
End Try

ou vaut il mieux faire

if not MyDataSet.Table(0).Rows(i).item("Nom") is nothing
Nom = MyDataSet.Table(0).Rows(i).item("Nom").ToString

Je pense que le probleme dans le 2° cas est que si une erreur inconnue arrive le catch la gerera alors que la 2° solution non.

qu'en pensez vous ?

merci

utilise try catch

merci de ta reponse, j'ai toujours fait comme cela mais l'autre jour un programmeur m'a dit que c'etait caca du coup par acquis de conscience j'ai posait la question. Le fait que ce soit un MCAD de microsoft me rassure :)


merci a+

Je confirme que c'est du gros caca de tester avec un try catch.
Et encore, c'est pour resté poli et modéré.

Pour info, je bosse sur une appli qui rame... mais qui rame.. pourquoi ? Paske ça a été développé par un junior qui fait tous ses tests avec des try catch, et la gestion d'erreur, ça coute plus cher en temps qu'un bête "if".

Donc le try catch, quand tu penses que ça peut planter, te le mets, mais ça ne te dispense pas de faire les tests indispensables.

Après, pour un TP ou un devoir de programmation on s'en tape, mais pour une appli pro, c'est ce qu'on appelle une faute professionnelle.

PS : pour info, dans ton cas précis, y'a encore mieux à faire (je te le note en C# paske je parle pas VB :

Code:

---

1 2 3

object value = MyDataSet.Table[0].Rows[i].item["Nom"]; if(value != null) string machaine = value.ToString();

---

Comme ça tu évites de rappeler tes accesseurs de table, de rang et d'item.

Juste histoire de preciser un peu les propos de Mose; effectivement le try/catch c'est mal si c'est utilise pour gerer le comportement normal de ton appli (comme tu l'as fait dans ton exemple), sinon c'est une bonne chose :). Certes ca alourdit le code mais ce qui est couteux c'est la levee d'exception et pas l'utilisation du try/catch en soit.
De plus il est indispensable d'utiliser le try/catch/finally (ou le using qui n'est au final qu'un try/finally) pour liberer les ressources, notamment au niveau des fonctions d'acces aux donnees (et lorsque l'interface IDisposable est implementee).
Bref, le try/catch/finally c'est bien, faut juste correctement s'en servir :).

Je viens de relire ma réponse, et c'est vrai qu'elle incomplète en plus d'être véhémente ;)
Je reformule, pour aller dans le sens de Nip :

Il faut utiliser les deux : et les tests, et le try catch.

* Les tests c'est quand tu sais qu'il y a une chance que l'utilisateur ou de développeur qui va utiliser ton code va faire une connerie. Bref tu prévois les mauvaises utilisations, paske les utilisateurs comme les codeurs ne lisent jamais les manuels ou l'aide des méthodes avant de s'en servir.
- exemple 1 : tu vérifies que ton paramètre n'est pas null avant de l'utiliser.
- exemple 2 : tu vérifies la taille de ton tableau avant d'aller taper dedans (montableau[5])

* Les try catch, c'est quand il y a des choses que tu ne peux pas tester
- exemple 1 : tu as ouvert ta socket et tu écris dedans, mais l'utilisateur peux débrancher son cable réseau n'importe quand. Donc à chaque lecture/écriture dans ta socket, il faut mettre un try catch.
- exemple 2 : tu écris un fichier sur disk, mais tu ne sais pas si le répertoire est protégé en écriture, si l'utilisateur courant à le droit d'écrire dedans, ou si le disque est plein (encore que... ça peut se tester, mais c'est chiant :))

* Si tu codes en N-tiers, de manière générale, tu peux mettre des try-catch dans toutes les méthodes ta couche interface. Comme ça dès qu'il se produit une erreur, ça évite que ton utilisateur se prenne soit une erreur serveur (ASP.Net) soit une erreur Windows (winform).
Avantage : tu n'a pas besoin d'en mettre dans les couches basses, l'exception va se propager et remonter mais elle sera catchée juste avant que l'utilisateur s'en rende compte, et tu pourras diagnostiquer le problème plus facilement grâce à la call stack.
(Perso à cet endroit je log monexception.ToString(), et ce de façon récursive sur monexception.InnerException pour avoir un diagnostic complet de l'erreur).
(euh... je sais pas si je suis très clair là...)

* Oui c'est relou. Très relou même. En fait, pour être sincère, tu peux mettre plus de code de vérification que de code d'action. Mais c'est comme ça qu'on distingue le boulot d'un vrai professionnel à celui d'un étudiant. Le vrai professionnel il anticipe tous les cas parce qu'il sait qu'il y a forcément un moment où un gentil con va mal utiliser son appli / son code et venir pleurer en disant "ça marche paaaaaaas". L'étudiant, il s'imagine que le monde est beau et que les utilisateurs sont tous aussi forts que lui :)

Citation:

---

Envoyé par Mose

(Perso à cet endroit je log monexception.ToString(), et ce de façon récursive sur monexception.InnerException pour avoir un diagnostic complet de l'erreur).

---

En effet c pas trés clair, tu peux donner plus de precision

merci

bonjour,
suite a ce debat je viens de reprendre une classe avec 80 variables encapsulées. j'ai mis un System.diagnostic.StopWatch

1- une requete me renvoie une ligne dans un dataset
2-Tout d'abord j'ai laissé try catch => Stop watch 798 ms à la 1° execution et 672 a la 2° execution
3-J'ai mis Si MonChamp est Null=>Stop watch 18ms à la 1° execution et 5a la 2° execution
je suis sur le cul :)

merci a+

Citation:

---

Envoyé par Mose

(Perso à cet endroit je log monexception.ToString(), et ce de façon récursive sur monexception.InnerException pour avoir un diagnostic complet de l'erreur).

---

Une Exception c'est récusif. Enfin c'est chaîné pour être plus précis.
C'est à dire que ça peut contenir une autre exception, dans la propriété InnerException.
Y'a pas mal de couches dans .Net qui font un catch(Exception exc), et qui derrière font un throw new MonExceptionPerso("mon message d'erreur", exc)
C'est à dire que l'exception d'origine va être renvoyée à l'intérieure de l'exception renvoyée, dans la InnerException.

Quand tu fais tes catch d'Exception, il faut toujours vérifier qu'il y a une InnerException dans ton exception, ça te donne des détails supplémentaires sur ce qui a causé l'erreur.

C'est indispensable notamment quand tu bosses avec des middleware qui encapsulent tout le temps les exception .Net dans des exceptions custom.