Discussion :

[gaetan13]

Bonjour,
J'ai une petite question concernant la capture et le gestion des exceptions. J'ai une classe qui gère la communication avec le port série. Je l'ai conçue pour qu'elle soit la plus autonome possible pour que les développeurs qui l'utilise aient le moins d'action possible à faire.

Dans cette optique, elle capture les exception qu'elle cause elle même. Je m'explique : je laisse l'utilisateur capturer uniquement les exceptions qu'il a pu causer en utilisant une fonction etc... Si une exception est due par exemple à un problème de lecture d'un paquet entrant, l'exception sera mise dans le log mais l'utilisateur ne pourra pas la capturer. Idem si on déconnecte le câble, l'utilisateur ne pourra pas capturer l'exception que génère le SerialPort vu que je la capture dans ma classe.

Je sais pas si c'est une bonne pratique et je vois pas trop comment faire pour pas que des exceptions soient déclenchées alors que l'utilisateur n'a rien demandé... Je me sens un peu coupable, est-ce une bonne pratique ?

[Pol63]

tu peux masquer les exceptions, mais pour avoir une couverture fonctionnelle complète il faut alors des évènements pour ces cas
comme ca si le développeur s'en fout il ne fait rien, s'il veut être averti il s'abonne

[rv26t]

Bonjour,

Des info détaillées sur les exceptions : Comprendre la philosophie des exceptions sous .NET

[Pol63]

et tout dépend de ce que fais le code

si c'est une classe qui s'occupe de dialoguer, sur la méthode qui envoie des données, il vaut mieux thrower s'il y a une erreur, un évènement n'ira pas

par contre si c'est une classe qui s'occupe de transformer les informations (donc très autonome) tu peux exposer des propriétés avec l'état de la connexion, les valeurs obtenues, et donc lever un event lors de la déconnexion pour qu'un développeur puisse le notifier sur l'interface de l'appli

[gaetan13]

Merci pour votre réponse. Oui, actuellement je raise des événements pour informer de ce que l'exception a entrainer comme comportement (exemple déconnexion). Ça c'est pour la partie autonome. Et sinon quand l'utilisateur utilise des méthodes qui entrainent une action spécifique provoquant une exception je ne la bloque pas.

Bon tout me semble en cohérence du coup Merci beaucoup