2010-07-30 2 views
0

Je construis un cadre dans lequel j'ai besoin de vérifier les erreurs pour les classes. Je ne peux pas utiliser d'exceptions (non autorisées). J'ai décidé de faire une classe héritée par toutes les classes qui ont besoin de rapports d'erreurs qui ont des fonctions telles que ReportError() [pour la classe elle-même] et GetError() [pour obtenir la dernière erreur - utilisée par l'appelant ] ainsi que des fonctions pour ajouter des erreurs personnalisées appelées AddError (/ * arguments * /). La classe a un type énuméré appelé FW_ERROR_TYPES avec quelques types d'erreur par défaut qui sont les plus communs. Par exemple, FW_ERROR_INIT (échec de l'initialisation correcte), FW_ERROR_CTOR (erreur lors de la construction de l'objet) etc. Lorsqu'une classe signale l'erreur, une description facultative peut également être ajoutée, qui est enregistrée (utile pour une analyse ultérieure pour voir ce qui s'est passé) faux). Tout cela va bien, et fonctionne plutôt bien pour mon but.Problème de conception en ce qui concerne l'héritage des énumérations

Le problème vient lorsque je veux ajouter des erreurs personnalisées. Les erreurs personnalisées ne peuvent pas être ajoutées en tant que FW_ERROR_TYPES car l'énumération n'est pas héritée par la classe qui hérite de la classe d'erreur. Je n'ai pas vu ce problème pendant que je concevais la classe d'erreur. Mon « design » original était que lorsque GetError() est appelée pour obtenir la dernière erreur, il retournera un FW_ERROR_TYPES, donc une erreur de compilation sera générée lorsque utilisé comme ceci:

if (SomeClass->GetError()) // OR 
if (SomeClass->GetError()) == true) 

C'est, cela force celui qui l'utilise pour vérifier spécifiquement contre FW_ERROR_TYPES. Quand j'ai découvert que les classes héritant de la classe d'erreur ne pouvaient pas étendre enum en FW_ERROR_TYPES, je devais utiliser une énumération générique et je devais forcer GetError() à retourner un entier non signé. J'ai défini l'entier non signé comme FW_ERROR_TYPE de sorte qu'au moins il y ait une indication qu'un code d'erreur est renvoyé.

Ouf! Donc ma question est, comment puis-je améliorer sur cette conception (ou l'abandonner et aller avec un meilleur)? Existe-t-il un moyen d'hériter des types énumérés? J'ai regardé le site codeproject et trouvé une solution plutôt compliquée (si tout le reste échoue, je vais essayer). Toute aide serait grandement appréciée.

Merci!

Répondre

1

Vous pourriez avoir votre valeur d'erreur être une classe au lieu d'une énumération. Vous pouvez avoir une classe d'erreur de base FwError, avec des méthodes utiles comme GetMessage(), puis avoir une variété de types d'erreur héritant de cette classe d'erreur de base. Lorsque vous devez vérifier si une erreur renvoyée est un certain type d'erreur, vous pouvez utiliser les informations de type à l'exécution pour vérifier les types d'erreur. Si vous devez créer un nouveau type d'erreur, vous pouvez hériter de la classe d'erreur de base ou d'une sous-classe plus spécifique. Si un appelant obtient une erreur d'un type dont il n'a jamais entendu parler, le polymorphisme garantit qu'il peut toujours le manipuler comme une base FwError et imprimer un message significatif.

+0

Ce n'est pas une mauvaise idée du tout. Le seul problème que je prévois est que le RTTI est une opération coûteuse, alors que la vérification par rapport à une énumération numérotée est beaucoup plus rapide. Merci pour l'idée, car je vais garder cela à l'esprit quand j'ai besoin de ce type de vérification d'erreur sans trop me soucier des performances. – Samaursa