Je suis un développeur C plutôt que C++, mais j'essaie de te répondre objectivement.
Exception ou code de retour, la difficulté de gestion des erreurs reste la même, où la gère-t-on et quelles actions complémentaires faut-il réaliser : souvent une action au sein de l'api (réinitialisation ressources) et une plus globale (compteur d'erreur, etc....).
Mais dans le second cas le retour de fonction 'auto-documente' une gestion des codes d'erreur (tiens il y a un retour, est-ce que je dois les gérer ?), alors qu'avec un try/catch c'est beaucoup moins évident (il faut documenter je crois..., ou rencontrer au moins une fois l'erreur) pour l'intégration.
Et je me demande si le débogage du try/catch est aussi simple qu'avec un code de retour.
Mais surtout, j'ai trop souvent vu des personnes utiliser des try/catch sous prétexte que c'est nouveau pour finalement les gérer comme des return, et là question lisibilité : c'est zéro !
Au final ce n'est pas un argument d'abandonner une API pour cette gestion d'erreur, s'il y en a une et qu'elle est correctement documentée pour l'intégration il faut l'utiliser.
[^] # Re: Je n'aime pas la SFML
Posté par Selso (site web personnel) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 5.
Je suis un développeur C plutôt que C++, mais j'essaie de te répondre objectivement.
Exception ou code de retour, la difficulté de gestion des erreurs reste la même, où la gère-t-on et quelles actions complémentaires faut-il réaliser : souvent une action au sein de l'api (réinitialisation ressources) et une plus globale (compteur d'erreur, etc....).
Mais dans le second cas le retour de fonction 'auto-documente' une gestion des codes d'erreur (tiens il y a un retour, est-ce que je dois les gérer ?), alors qu'avec un try/catch c'est beaucoup moins évident (il faut documenter je crois..., ou rencontrer au moins une fois l'erreur) pour l'intégration.
Et je me demande si le débogage du try/catch est aussi simple qu'avec un code de retour.
Mais surtout, j'ai trop souvent vu des personnes utiliser des try/catch sous prétexte que c'est nouveau pour finalement les gérer comme des return, et là question lisibilité : c'est zéro !
Au final ce n'est pas un argument d'abandonner une API pour cette gestion d'erreur, s'il y en a une et qu'elle est correctement documentée pour l'intégration il faut l'utiliser.