Cela fait un moment que je réfléchis à ce problème et je me trouve constamment en train de trouver des mises en garde et des contradictions. J'espère donc que quelqu'un pourra produire une conclusion sur ce qui suit:
Privilégier les exceptions aux codes d'erreur
Autant que je sache, après avoir travaillé dans l'industrie pendant quatre ans, lu des livres et des blogs, etc., la meilleure pratique actuelle en matière de gestion des erreurs consiste à lever des exceptions, plutôt que de renvoyer des codes d'erreur (pas nécessairement un code d'erreur, mais type représentant une erreur).
Mais pour moi cela semble contredire ...
Codage aux interfaces, pas aux implémentations
Nous codons pour des interfaces ou des abstractions afin de réduire le couplage. Nous ne savons pas ou ne voulons pas savoir le type et la mise en œuvre spécifiques d'une interface. Alors, comment pouvons-nous savoir quelles exceptions nous devrions chercher à attraper? L'implémentation peut générer 10 exceptions différentes, ou aucune. Lorsque nous détectons une exception, nous faisons sûrement des hypothèses sur la mise en œuvre.
Sauf si - l'interface a ...
Spécifications d'exception
Certains langages permettent aux développeurs d'indiquer que certaines méthodes génèrent certaines exceptions (Java, par exemple, utilise le throws
mot - clé.) Du point de vue du code appelant, cela semble très bien - nous savons explicitement quelles exceptions nous devrions éventuellement intercepter.
Mais - cela semble suggérer un ...
Abstraction qui fuit
Pourquoi une interface devrait-elle spécifier quelles exceptions peuvent être levées? Que se passe-t-il si l'implémentation n'a pas besoin de lancer une exception ou a besoin de lancer d'autres exceptions? Il n’ya aucun moyen, au niveau de l’interface, de savoir quelles exceptions une implémentation peut vouloir déclencher.
Alors...
De conclure
Pourquoi les exceptions sont-elles préférées quand elles semblent (à mes yeux) contredire les meilleures pratiques en matière de logiciels? Et, si les codes d'erreur sont si mauvais (et que je n'ai pas besoin d'être vendu sur les vices de codes d'erreur), existe-t-il une autre alternative? Quel est l'état actuel (ou à venir) de la gestion des erreurs qui répond aux exigences des meilleures pratiques décrites ci-dessus, mais ne repose pas sur un code d'appel vérifiant la valeur de retour des codes d'erreur?