Je travaille sur une bibliothèque conçue pour communiquer (sur la communication série RS232) avec des périphériques externes. Je pensais que la stratégie de traitement des erreurs et des exceptions semblait être une méthode standard appropriée de l'industrie de signaler des erreurs.
J'ai donc lu peu de directives sur les exceptions. Un stipule assez clairement que je devrais N'utilisez pas de codes d'erreur en raison de préoccupations que des exceptions pourraient affecter les performances négativement.
Autre m'a dit de ne pas jeter Exception dans les cas normaux:
n'utilisez pas d'exceptions pour des erreurs normales ou attendues, ou pour un flux de contrôle normal.
Je ne suis pas capable de dessiner une ligne claire entre les cas normaux / attendus et autres. Par exemple, dans ma bibliothèque, une opération peut échouer car:
Je peux penser à tout ce qui précède comme des problèmes attendus, car ils peuvent se produire très souvent dans la pratique (en infactuellement, de nombreux meurtres marketing m'appellent pour résoudre le problème ^ dans mon logiciel uniquement pour ne pas connaître le câble à leur ordinateur portable). Donc, peut-être que des exceptions ne devraient pas être jetées car sinon un programmeur d'application devra les attraper à de nombreux endroits (beaucoup de blocs de capture ne sont pas aussi agréables que je pense).
D'autre part, j'ai aussi tendance à penser que ce sont toutes des erreurs que je dois faire une manière en quelque sorte faire rapport au programmeur d'application, et une exception semble être la meilleure façon de le faire. Si je n'utilise pas d'exceptions, je devrai signaler ces problèmes en utilisant un code d'erreur ou une erreur enums. (Ugly, je sais).
Quelle approche pensez-vous que je devrais prendre?
9 Réponses :
Avec RS232, sauf si vous avez activé la main de main du matériel (et la plupart du temps, les gens ne le voient pas. Il n'y a aucun moyen pour vous de dire si un appareil est même connecté, autre que le fait que rien n'est envoyé au PC.
Je classerais 1 et 3 ensemble en tant que RS232TimeTorRor et 2 en tant que RS232AuthentiollingError, probablement.
En règle générale, un TimeOtorRor indique que le périphérique distant est enfermé ou n'est tout simplement pas connecté. Une erreur d'authentification est une sorte de ProtocolError, mais subtilement différente de la communication, mais le périphérique distant "vient de dire non" de créer une connexion avec le PC.
Je pense que les paramètres d'exception sont bien justifiés: vous ne vous attendriez jamais à une erreur de délai d'attente pendant les opérations normales, ni d'une erreur d'authentification.
La bibliothèque est destinée à être utilisée pour la communication avec de nombreux appareils (32 appareils à la fois) et il doit être aussi rapide que possible car il sera utilisé dans l'environnement de production. Pensez-vous que soulever l'exception trop souvent affectera la performance?
Si cela doit être aussi rapide au point où jeter des exceptions est un problème, vous devez écrire la bibliothèque en C. Si vous soulevez une exception de délai d'attente, vous ne revenez plus immédiatement au matériel et voyez une autre exception - Vous ignorez cet appareil jusqu'à ce que vous soyez explicitement dit de y retourner.
@Hemant: retournez la question. Si les erreurs se produisent tout le temps, pensez-vous que cela affectera la performance? Vous attendez-vous souvent des erreurs? La performance sera-t-elle touchée par l'utilisation d'une exception étant-elle comparée à celle de la performance impliquée dans la récupération de l'erreur au niveau suivant d'abstraction?
Vous développez une bibliothèque , un composant qui sera utilisé par d'autres applications.
Par conséquent, dans les cas prévus que vous mentionnez, j'utiliserais certainement des exceptions pour communiquer à l'application appelante que quelque chose ne va pas. Vous devez définir une exception personnalisée pour chacun de ces scénarios, puis documenter clairement quand ils peuvent se produire.
Ceci permet ensuite au code du client de l'application de prendre la décision de la meilleure façon de procéder. Seule la demande du client peut effectuer cette décision et des exceptions clairement documentées l'aident considérablement.
La meilleure chose à propos d'une exception personnalisée est que vous pouvez fournir plusieurs données de données significatives / utiles relatives au problème / exception. Ces données sont également bien encapsulées dans un seul objet. Comparez ceci aux codes d'erreur et retournez des valeurs.
La performance peut être un problème, mais uniquement lorsque l'exception est lancée dans une boucle serrée ou une autre situation d'activité élevée. Pour éviter cela, vous pouvez également appliquer un motif utilisé par le .NET Framework, nommément fournir des méthodes .... () (p. Ex. de toute façon, j'irais avec des exceptions personnalisées initialement, puis effectuez des tests de performance pour voir en réalité que certaines parties de la bibliothèque peuvent nécessiter une optimisation. Tryparse () ) qui retourne booléen indiquant si une action a réussi ou échoué.
En ce qui concerne la performance, je n'ai vu qu'une seule fois lorsque la performance est entrée en place et qu'il y avait littéralement des centaines d'exceptions étant jetées et restonnées à l'arrière. Nous avions une opération qui pourrait être faite de deux manières, une fois parfois travaillée mais jeté une exception quand elle ne l'a pas fait, et l'inverse de la manière dont la voie est requise. Nous avons décidé que la voie de réflexion devrait être une baisse si nous ne pouvons pas le faire sans réflexion. Les exceptions ont été levées de manière aussi souvent que c'était beaucoup plus rapide d'utiliser toujours la méthode de réflexion (la différence était l'utilisateur qui attend 10 secondes contre des fractions de seconde).
si vous lancez ou non une exception est une conséquence du type de la fonction.
Je suppose que je dis que vous devriez pousser le problème de "Dois-je jeter une exception?" à "Quelles méthodes les gens appelleront ma bibliothèque?" Avec la mise en garde que les exceptions que vous lancez devraient être
J'utiliserais des exceptions, dans l'approche suivante (inspirée par le design-by-contrat)
De cette manière, si l'utilisateur de l'API peut coder sa logique clé à l'aide de Structures IF-else.
Si des situations inattendues surviennent (en raison de problèmes de synchronisation subtils, par exemple, une exception sera lancée: le développeur peut attraper cette exception et y faire face. MAIS NOTE: Cela ne doit pas nécessairement être à l'endroit où la méthode a été invoquée: elle peut être plus haute / plus tôt dans la pile d'appels, à un endroit central où toutes les exceptions étranges sont gérées
J'ai fait des travaux sur l'analyse automatisée du code de manutention des erreurs dans des programmes C multimobiliers de C. Celles-ci étaient basées sur des normes de codage nécessitant une inspection manuelle et une propagation des codes d'erreur. Il s'avère que les développeurs n'aiment pas écrire ce code, ils l'oublient et ils en font facilement des erreurs. En fait, nous avons trouvé 2 écarts des normes de codage (2 défauts, on pourrait dire) pour 1000 lignes de code C.
Résumé: (1) J'utiliserais des inspecteurs booléens (2) des exceptions peuvent être attrapées à des endroits plus élevés dans la pile d'appels; (3) s'appuyer sur des codes d'erreur est dangereux dans la pratique.
Conception par contrat pour la victoire!