est-il recommandé de mettre un bloc de try-catch dans chaque fonction qui ouvre une connexion DB et de loger l'erreur là-bas, ou devrais-je plutôt prendre des erreurs dans une couche supérieure de l'application?
try
{
Category myCat = DataTools.GetCategoryByName("myCat");
// other stuff
}
catch(Exception e)
{
// log error here?
}
4 Réponses :
Comme toujours, cela dépend, mais en général, n'atteignez que si vous pouvez faire quelque chose à ce sujet, ou si vous avez du code spécifique (par exemple, une nouvelle tentative), sinon, laissez l'exception bulle et la plus grande couche peut se connecter / traiter avec elle de manière centralisée.
Toute autre solution entraîne beaucoup de code de journalisation entrecoupé avec toute la logique commerciale.
J'aime mieux la première approche, mais vous devez toujours résoudre ce que faire d'autre pour faire le bloc de capture ...
Je ne gère généralement que des exceptions dans l'interface utilisateur, tout en ci-dessous, je le jette toujours au niveau supérieur. De cette façon, la trace de la pile a été maintenue tout le chemin. Vous pouvez toujours vous connecter et le jeter.
Je l'ai utilisé avant aussi:
Lorsque vous attrapez des exceptions, essayez toujours d'utiliser l'exception la plus précise possible. Par exemple, lors de l'utilisation de SQL Server, saisissez la SQLException car elle contiendra beaucoup plus d'informations sur l'exception que l'exception générique. Vous pouvez obtenir des numéros de ligne réels et d'autres éléments de diagnostic utiles.
Après avoir été extraite et enregistrée tout cela est pertinent, reportez-vous à l'exception ou envoyez-la dans une exception moins spécifique, telle qu'une exception ou une exception invalide et une exception. Vous pouvez ensuite attraper ces exceptions plus génériques à des niveaux plus élevés. P>
try
{
// Execute DB call here
}
catch(SqlException exp)
{
// Log what you need from here.
throw new InvalidOperationException("Data could not be read", exp);
}