Discussion :

[Le Grand Habchkleu]

Salut tout le monde.

J'ai une Classe X qui contient du code métier. Dans X je peux avoir parfois des appels à des méthodes d'une classe Y, qui contient tout ce qui est transactions avec la BD. Une méthode nommée maMethode() exécute une requête sur la BD et me retourne le résultat dans un DataSet.
Et biensur dans tout ça je dois gérer une éventuelle exception de type SqlException qui pourrait survenir après un problème quelconque au niveau de la BD.

Alors ma question est la suivante : vaut-il mieux gérer l'exception, c'est à dire placer le try-catch
- à l'intérieur de la méthode maMéthode(), au niveau de la classe Y
- à l'extérieur de la méthode, c'est à dire au moment de l'appel à maMéthode(), au niveau de la classe X

En terme de design/qualité de code, quelle possibilité serait la meilleure?
Merci beaucoup.

[laedit]

Vu que c'est une SqlException, cela concerne uniquement la classe Y vu qu'il n'y a qu'elle qui est en contact avec la base de données.

Donc personnellement je mettrais le try/catch dans MaMéthode.

[Le Grand Habchkleu]

merci !
Mais sinon, quid du retour de la méthode? Imaginons qu'elle ait crashé alors qu'elle est appelée est dans une boucle qui fait un tas de traitement. Si la méthode crashe, comment vaut-il mieux gérer ce cas à l'extérieur de la méthode c'est à dire au niveau de la classe X ?

[laedit]

Mettons que quand tu as une exception, la méthode retourne null à la place du DataSet attendu.

Dans ce cas, tu fais une vérification if(myDataSet != null) avant d'utiliser le DataSet.

[Le Grand Habchkleu]

C'est exactement ce que j'ai fait, mais à un moment je me suis posé la question pour savoir si c'est un bon design ou pas..

Merci en tout cas !

[Pol63]

si c'est pas mal je pense
la méthode qui travaille dans la base, elle s'occupe des erreurs
et celle qui est extérieur en théorie elle s'en fout de savoir pourquoi ca a pas marché, elle veut juste savoir si ca c'est bien passé ou pas

donc soit une fonction qui retourne null quand ca se passe mal au lieu d'une instance et le tester
soit une fonction booléenne qui te remplit un paramètre de la fonction et retourne false si ca c'est mal passé

[Le Grand Habchkleu]

Merci bcp les gars !

D'ailleurs si vous auriez un genre de document qui parle de bon design, pas forcément pour un langage précis mais dans l'absolu, je suis prenneur.

Encore merci.

[oyigit]

Pour ma part, je vois plutôt une classe qui remonte une exception "typé", surtout pour une classe d'accès aux données. De ce fait, les classes qui appelent la classe Y ont le choix. Soit, elles catch l'exception, et continue leur traitement, soit elle propagent l'exception. En interceptant l'exception dans la classe Y, tu fige le fonctionnement de la méthode. Les classes appelantes ne savent pas si une erreur est survenue.

[Le Grand Habchkleu]

Merci oyigit.
Et donc c quoi le design qui te parait plus élégant?

[laedit]

En interceptant l'exception dans la classe Y, tu fige le fonctionnement de la méthode. Les classes appelantes ne savent pas si une erreur est survenue.

Pas si tu te débrouille pour que les classes appelantes le sachent par le biais d'un booléen par exemple.

Et ça peut être un peu lourd de devoir mettre à chaque fois un try/catch quand tu appelle une méthode "à risque".

[oyigit]

Je sais pas si on peut parler d'élégance

Il faut d'abord penser ton archi de façon à satisfaire tes besoins. Cela dépend de la taille de ton projet, du nombre de développeurs....

Mais en prinicipe, les couches métiers de ton projets sont découpées. Tu as tes classes d'accès aux données (dans ton cas la classe Y) dont le rôle est de récupérer des éléments en base de données. Je ne trouve pas logique qu'une classe d'accès aux données bloque une exception et retourne null... Je pense plutôt qu'elle devrait intercepter l'erreur et propager une erreur typer que tu aura renommer (par ex : MyDatabaseAcessException ), Tu as donc un catch sur les Erreurs SQL. En générale, les classes d'accès aux données ont peu d'intelligence. Ensuite viens la classe de Service (Business). Elle fait l'intermédiaire entre des classes dédiée aux applications (interfaces ou autres) et les classes d'accès aux données. Dans ton cas, il s'agit de la classe X. Les classes de services, sont plus intelligentes et traite les cas fonctionnelles de ton application (elle sont capable de déterminer si tu es dans un cas normal ou pas). Imaginons que tu as une boucle dans ta classe X. A l'interieur de la boucle tu peux déterminer si une erreur SQL provoquée par la classe Y est bloquante ou non. Si elle est bloquante, tu peux propager ton erreur (donc pas de try catch). En revanche, si les erreurs ne sont pas bloquantes (imaginons le cas d'une insertion multiple dans une boucle, si une insertion est en erreur, on doit quand même insérer les autres données), tu a un catch dans ta boucle, qui bloque la propagation de l'erreur est permet l'insertion des données qui suivent.

[oyigit]

Et ça peut être un peu lourd de devoir mettre à chaque fois un try/catch quand tu appelle une méthode "à risque".

C'est marrant, bcp de gens dise cela parce qu'ils ont entendu cela. Mais as-tu déjà réaliser des tests de performances sur la gestion des exceptions ? Personnellement, je l'ai déjà fait, de long en large, sur des applications de différentes tailles. C'est une idée fausse que de penser que de mettre des try/catch est lourd. Effectivement, c'est un peu plus lourd que de na pas gérer d'exception. Mais la différence est minime et largement négligeable. Tu peux te monter un projet de test, et faire le test sur une boucle de 1 à 10000000, mesure les temps entre les différentes façon de faire (try/catch sur les deux niveaux, try catch de la classe "Exception", try catch par exception typé, try catch dedans ou hors de la boucle, pas de try\catch...). Tu peux faire test sur différentes applications, plus ou moins grosses, de différentes types (winform, web, appli console, web services)... Tu verras, les résultats sont surprenants. Le plus lourd dans tout ça (quoique largement négligeable) ce n'est pas le try\catch, mais la construction de l'exception (car la pile d'exception doit être produite). Une fois l'exception SQL générée, elle est de toute façon construite.

[laedit]

Je ne pensais pas à ça quand je disais que c'était lourd. Je l'ai employé dans le sens de contraignant

Par contre, pour avoir fait des tests moi aussi (parce-que le on dit c'est sympa mais bon), le try/catch n'est lourd que quand il attrape une exception. Et même si généralement, ça prend pas énormément de temps non plus, c'est toujours moins rapide qu'un événement.

[Le Grand Habchkleu]

Merci pour vos réactions les gars je suis en train de bien étudier vos idées.
D'ailleurs si vous auriez une sorte de tuto ou un doc qui montre les bonnes pratiques de la gestion d'erreur ça m'aiderait bcp.

[Pol63]

ce qui est bien c'est dans les catch tu enregistres les infos de l'erreur (message et stacktrace au moins, après innerexception peut aider et le mieux c'est de sérialiser l'objet qui déclenche l'erreur pour avoir des infos d'état)
si tu peux les envoyer par mail ou direct dans une base de données chez toi c'est pratique pour éplucher les bugs et faire des mises à jour