Discussion :

[UNi[FR]]

Bonjour,

je développe depuis un moment maintenant en .NET plus particulérement depuis quelques mois en .NET 3.0

Actuellement je met des try...catch un peu partout en utilisant les exceptions génériques et j'enregistre les erreurs dans un fichiers de logs.

Comment faire pour optimiser la capture des erreurs ?

et plus particuliérement

J'aurais voulu savoir quand et comment bien utiliser des TRY...CATCH

[Chubyone]

Il faut patienter un petit peu (il y a deja des éléments de réponses matant les best practices java)

http://www.developpez.net/forums/sho...d.php?t=433213

Mais si certains veulent deja donné leurs avis...

Pour ma part j'utilise surtout les try catch pour toutes entrées / sorties de l'application/assembly : des que ca ne me concerne pas directement... Je suis censé maitriser tout ce qui se trouve à l'intérieur...
Mais je sais que je ne les utilises pas du tout au mieux Pour ca que j'attends aussi ce best practice...

[ced600]

Une méthode d'utilisation des try catch que j'ai même bien c'est lorsque tu attrapes les exceptions que tu génères toi même.
Par exemple j'ai une appli où j'attrape les exceptions systèmes classique, mais aussi deux types d'exceptions que je génére.
par exemple une exception application lorsque je détecte l'absence du fichier de conf utilisé.
Ou une autre exception BNException, lorsque je détermine que le soft que je supervise est en vrac.
Pour gérer ces exceptions j'ai créé 3 classe d'exceptions qui dérive d'une classe mère abstraite qui hérite d'Exception.

Sinon de façon générale, lorsque ne peut être sur que ce que tu utilises ne gènère pas d'exception il faut mettre un try catch.
Par exemple un accés en écriture sur un fichier partagé par d'autre appli peu générer une exception si une autre appli à la main dessus.
Dans ce cas la tu peux mettre un try catch et dans le catch t'arranger pour recommencer l'opération plus tard.
Une façon comme une autre de gérer ce genre de chose.

[mlebreton]

D'une manière générale on croit souvent que le métier d'un développeur consiste à coder le process attendu.

En fait, le vrai métier d'un développeur consiste à surtout prévoir tout ce qui pourrait se passer, à traiter tous les cas particuliers, toutes les situations. Cela inclut les exceptions. Dans un process, bien souvent, il faut moins de temps pour coder le cas général qu'il n'en faut pour coder les cas particuliers. C'est ce qui explique qu'une grande majorité des codes ne sont pas 'propres'.

Il faut reconnaître que nous sommes souvent contraint par le temps et le budget. Alors je me suis fixé quelques règles :

1) Même si je n'ai pas le temps de coder tous les cas particuliers et toutes les réactions à toutes les exceptions, je prends le temps de noter sous forme de commentaires tout ce qui pourrait arriver et que je n'ai pas codé. Cela m'a sauvé la vie un nombre de fois considérable lorsqu'il m'a fallu corriger certains bogues.

2) J'ai souvent constaté que plutôt que de chercher à gérer des erreurs il est préférable de chercher à les éviter. Il est plus simple d'écrire un code contenant plein de conditions, de tests avant chaque action plutôt qu'un code contenant plein d'exceptions.

3) L'usage de la structure try / finally et des destructeurs (ou IDispose) est beaucoup plus important que la structure try / catch. Quoi qu'il arrive, même si nous ne gérons pas nos exceptions, notre code doit toujours tout faire pour ne pas placer le programme dans un états intermédiaire ou non terminé. Lors de mes audits, j'ai vu une quantité astronomique de code qui plaçaient la base de données dans un états incohérent engendrant des conséquences importantes.

[ced600]

+1
Tout à fait d'accord.
Le but dans la gestion des erreurs, des exceptions, c'est de faire en sorte que l'appli reste toujours fonctionnelle, quitte à alumer un warning si quelque chose ne va pas.
Imaginez vous que les appli utilisé par les banques pour le transfert d'argent plantent ->
Après le cas que j'ai présenté est en fait d'utiliser les exceptions comme moyen de com interne à l'outil.

1) Même si je n'ai pas le temps de coder tous les cas particuliers et toutes les réactions à toutes les exceptions, je prends le temps de noter sous forme de commentaires tout ce qui pourrait arriver et que je n'ai pas codé. Cela m'a sauvé la vie un nombre de fois considérable lorsqu'il m'a fallu corriger certains bogues.

+2
C'est une façon de faire très appréciable bien que comme tu es dit la pression que l'on peut avoir des fois (deadline pour hier, peu d'effectif, un effectif non qualifié, changement d'avis constant du client sur les spec accepté par ton chef,...) font que certaine fois on se dit : Merde j'ai pas le temps pour ces *$£!ù% de commentaires.

[Graffito]

Bonjour,

Personellement, je n'utilise les try catch que quand c'est l'unique moyen d'obtenir une condition ou un événement.

Une execution massive des instructions dans les catch peut pénaliser les performances; par exemple, si on fait une analyse lors d'un chargement de données avec des try i=int.Parse(chaine) catch ... et que l'on tombe souvent sur le catch. C'est sans doute une des raison de l'existence de la fonction TryParse.

De même, (sauf cas très particulier) les throw ne me servent qu'à signaler que l'on rencontre un cas anormal qui n'aurait jammais du se produire si la programmation était Ok (en fait, ca détecte une bug).