C# Création d'une classe de vérification d'erreur?

Question

Je suis très nouveau à la POO, et dans le programme sur lequel je travaille, j'ai une classe Utilitaires qui contient des méthodes générales. Dois-je inclure ma vérification d'erreur dans la classe Utilitaires ou devrais-je créer une nouvelle classe juste pour vérifier l'erreur?

Answer 1

Les classes «utilitaires» ont tendance à devenir monstrueuses - gardez le code de vérification d'erreur séparé.

Answer 2

Je ne sais pas exactement ce que vous voulez faire, mais il y a fort à parier que les classes de vérification d'erreurs ne devraient pas être dans votre classe Utilities. La gestion des erreurs est une classe de fonctionnalités qui justifie ses propres classe (s).

Rappelez-vous également que la POO est et non en mettant vos fonctions et vos routines en classe. OOP fait des classes qui représentent des choses. Evitez autant que possible les classes "Utilities".

Answer 3

En général, je gère les erreurs lorsque j'écris le code, ou je laisse l'appelant gérer les erreurs (c'est-à-dire que les exceptions dépassent la pile des appels). Peu importe que ce soit une fonction d'utilité ou non.

public static class Utility 
{ 
    public static string GetSomeString(string someOtherString) 
    { 
     try 
     { 
      // something 
     } 
     catch (exception ex) 
     { 
      // handle error 
     } 
     return result; 
    } 
} 

Answer 4

Je ne pense pas non plus. Les erreurs sont généralement des exceptions, qui sont les classes elles-mêmes et traitées exactement sur place où vous savez comment les gérer. Si vous recherchez des tâches de journalisation ou des tâches similaires, vous devez utiliser un cadre fini pour cela, tel que Log4Net, ou utiliser AOP tel que fourni par PostSharp.

Answer 5

La vérification d'erreur, une telle validation d'entrée devrait aller avec ce qui doit être vérifié - à moins que ce soit plutôt complexe, auquel cas il devrait être déplacé vers des méthodes séparées dans la classe de la chose vérifiée. Si c'est encore trop complexe pour cela, une classe séparée dédiée à la validation devrait être faite. La classe de validation doit être imbriquée dans votre classe principale, ou elle doit être marquée internal. Qu'en est-il de l'utilisation de l'événement Application_Error dans le fichier Global.asax?

Answer 6

Cela se déclenche quand une erreur non gérée se produit dans l'application.

Answer 7

Il existe différentes formes de vérification des erreurs

Si vous voulez dire la vérification des erreurs dans le sens de l'id de validité jsut faire dans le code ... quand vous trouvez que vous avez des tests communs chaîne EG a une longueur, peut-être un regex ... les ints ont une gamme ... je me retrouve avec une classe statique avec ces tests mais c'est tout simplement un refactoring. Je finis avec une classe statique avec des sous-classes statiques pour accéder aux méthodes ...

tests unitaires

Ceux-ci seraient dans différents projets au code principal à nouveau simplement de définir la portée des méthodes.

Erreur lors de la vérification. J'ai tendance à utiliser les instructions debug.assert dans tout le magasin pour la vérification générale des erreurs dans mes méthodes et fonctions pour tester les hypothèses pendant le débogage - j'ai tendance à les utiliser comme une forme faible de test unitaire.

Exception Gestion

Cela dépend de la zone que vous travaillez. Les exceptions dans le back-end ont très différents scénarios de gestion que l'avant.

pour iinstance WCF dispose d'une interface pour les exceptions. IErrorHandler iirc correctement, mais en ce qui concerne tout ce qui s'y connecte, il y a juste quelques fautes qui peuvent être déclenchées. Au backend, ces fautes peuvent être causées par des exceptions qui sont nombreuses et profondes, avec des données qui leur sont attachées à tous les niveaux. Vous ne voulez pas que ces données atteignent le front-end - mais vous devez l'enregistrer. Par conséquent, les exceptions au début ne sont que les décorations des vraies exceptions ... ce que je veux dire, c'est qu'au moment où vous aurez réglé votre problème, votre classe d'utilité sera énorme et vous voudrez commencer à la factoriser en plusieurs classes. .

Mais c'est pourquoi les exceptions doivent être dans un projet séparé - vous pouvez ensuite les référencer de partout et les réutiliser.

J'ai un projet que j'ai tendance à inclure pour gérer les erreurs. J'ai aussi un service WCF configuré pour que je puisse déclencher des exceptions afin de les enregistrer si nous les avons natives (pensez à la correction d'un bug ciblé).

Un exemple de la façon dont les choses évoluent est qu'une partie de ceci nécessite de sérialiser l'erreur et toutes ses données.

Donc, je voudrais éviter une classe d'utilité unique ... les choses qui commencent comme une seule méthode se développent généralement à un rythme alarmant une fois rampe portée commence. Ce genre de va au-delà de la POO dans des questions plus architecturales - vous devez savoir pourquoi vous voulez déplacer le code dans une classe d'utilitaires et vous devez alors décider si simplement le mettre il y a assez ... Je suggérerais il est bon d'en sortir, mais vous devriez aller plus loin et penser à la gestion des erreurs comme une solution complète à part entière. Son suppliant pour une solution de style SOA (ou au moins projet) imo .... c'est l'une de ces choses qui est non seulement commune à travers les applications, mais est également invariable ....