Dois-je utiliser les exceptions en C# pour assurer la compatibilité des classes de base ?

Question

D'un côté, on me dit que les exceptions en C# sont "coûteuses", mais de l'autre, je ne sais pas comment les mettre en œuvre.

Mon problème est le suivant : Je suis en train de faire un Stream dérivé, qui enveloppe un NetworkStream . Maintenant, le problème auquel je suis confronté est le suivant : Read(byte[] buffer, int offset, int count) . De la Stream pour cette fonction :

Les retours :

... ou zéro (0) si la fin du flux a été atteinte.

Le problème est que, dans le protocole que j'implémente, le côté distant peut envoyer un jeton "end of record" ou un jeton "please respond". De toute évidence, si cela se produit au début de l'enregistrement de l'utilisateur, il n'y aura pas de réponse. Read() cela pose des problèmes, car je dois retourner de la fonction, et je n'ai rien lu, donc je dois retourner 0, ce qui signifie que le flux est terminé, mais il ne l'est pas... est un EndOfRecordException ou similaire justifié dans ce cas ? Et dans ce cas, devrait-il toujours être levé lorsque ce jeton est rencontré (au début de l'écran de l'utilisateur) ? Read() et s'assurer que ces jetons sont toujours au début en retournant tôt) afin qu'il y ait une sorte de modèle sur la façon dont ces jetons doivent être traités.

Edit : Pour ce que ça vaut, ces jetons passent généralement de 3 à 10 fois par seconde. Au maximum, je ne m'attendrais pas à plus de 25 par seconde.

Answer 1

Les exceptions ne sont pas vraiment très coûteuses, mais elles ne sont pas nécessairement la meilleure façon de gérer le flux attendu/normal.

Pour moi, il semble que vous n'êtes pas vraiment mise en œuvre de a Stream - vous êtes encapsulant un flux vers un "lecteur". Je pourrais être tenté d'écrire une classe de lecteur spécifique au protocole avec des méthodes appropriées pour détecter la fin d'un enregistrement, ou encore Try... pour obtenir des données ou retourner false.

Answer 2

Il semble que vous ne devriez pas vraiment dériver de Stream si votre classe est concernée par les dossiers. Les flux ne sont généralement pas interpréter leurs données - ils ne sont qu'un mécanisme de transport des données d'un endroit à un autre.

Il y a eu des cas comme ZipInputStream en Java, qui finissent par être très confuses lorsqu'une simple InputStream comporte effectivement plusieurs flux, et vous pouvez passer de l'un à l'autre. D'après mon expérience, de telles API sont très difficiles à utiliser. Fournir une classe séparée pour implémenter la "séparation des enregistrements" qui peut fournir un flux pour les données. sur un disque me semble plus propre. Ensuite, chaque flux peut se comporter de manière cohérente avec les flux normaux. Pas besoin de nouvelles exceptions.

Cependant, je ne fais que deviner votre contexte sur la base des informations limitées dont je dispose. Si vous pouviez donner plus de détails sur la situation globale, cela m'aiderait.

Answer 3

Ce n'est pas si grave du point de vue des performances, mais quand même... Les exceptions sont prévues pour, eh bien, les exceptions. Des situations qui sont "inhabituelles". Si c'est la façon dont le flux sous-jacent se comporte, alors votre flux devrait être capable de le gérer. Si c'est le cas, il doit le gérer lui-même. Si ce n'est pas le cas, vous pouvez demander à l'utilisateur de définir une sorte de callback ou autre qui sera appelé lorsque vous recevrez un jeton "please respond".

Answer 4

Je crois que Stream -La classe dérivée ne doit traiter que les questions de streaming et respecter les règles de l'UE. Stream contrat sémantique. Toute la logique de niveau supérieur (interprétation des jetons EOF et EOR) doit être placée dans une autre classe.

Answer 5

Vous pouvez peut-être créer un enum que vous renvoyez, cet enum peut contenir des éléments pour EndOfRecord, EndOfStream, ReadOk ou tout ce dont vous avez besoin.

Les données lues peuvent être transmises en tant que paramètre de sortie.