Affirmer vs exception lors du développement de la bibliothèque

Question

Je développe une bibliothèque pour une utilisation ultérieure dans d'autres bibliothèques ou produits finaux. Supposons qu'un utilisateur utilise la bibliothèque de manière erronée - en passant une valeur inappropriée à une fonction publique, en appelant des fonctions dans le mauvais ordre, etc.

Dans ce cas, je peux lancer une exception, mais elles sont généralement conçues pour la version finale. produits et doivent être manipulés de manière appropriée, alors que nous avons ici une erreur de développeur qui n'a pas lu la documentation correctement. D'autre part, il ou elle est l'user de ma bibliothèque et donc l'assertion peut être une mauvaise façon de procéder (imaginez une assertion qui a déclenché dans le code que vous n'avez jamais écrit et que vous attendiez juste de travailler).

Jusqu'à présent, j'ai utilisé affirmations seulement à l'intérieur des fonctions et des méthodes internes privées, ainsi que me notifiant sur mes erreurs à l'intérieur de la bibliothèque. En cas de mauvaise utilisation par les utilisateurs de la bibliothèque, je lance toujours une exception avec une description d'erreur (et des conseils pour l'éviter).

Pensez-vous que ce soit une bonne approche? Si non, quelle règle utilisez-vous pour les assertions et les exceptions lors du développement d'une bibliothèque?

Answer 1

Oui, c'est la bonne approche. L'assertion est OK pour une utilisation interne dans des fonctions privées. Dans le cas où le client appelle la méthode publique avec des paramètres incorrects, une exception doit être levée. Le code incorrect doit planter le programme immédiatement, c'est la meilleure chance de corriger le bogue. C'est une bonne idée d'avoir différents types d'exception pour les situations attendues (fichier non trouvé, périphérique ne répondant pas, etc.) et les bugs de l'appelant comme valeur de paramètre incorrecte. Le code client doit capturer les exceptions attendues, laissant les exceptions inattendues non gérées. Lorsqu'une exception inattendue est levée, le programme client se bloque et le programmeur corrige le bogue.

Toutefois, si votre bibliothèque est écrite pour un usage interne dans la même société, il est possible de traiter les erreurs d'appel de méthode publique comme private, avec des assertions. Mais cette approche doit être fortement limitée et ne doit pas être utilisée pour des clients externes.

Answer 2

Assertions ne fonctionnera pas dans les assemblées de sortie, des exceptions est la seule façon de signaler l'utilisateur de la bibliothèque que quelque chose ne va pas