Il y a sûrement des scénarios où une exception peut faire l'affaire. Mais personnellement, je trouve que le nombre de pièges que ça pose éclipse le gain en lisibilité.
En fait, ce sont essentiellement les mêmes pièges que goto: on perd la maîtrise du flux de la fonction.
Dans ton exemple, une exception est lancée 50 niveau en dessous. Il faut donc, systématiquement, et à chaque étage:
s'assurer qu'il n'y a aucune fuite mémoire
s'assurer qu'une transaction commencée sera annulée et/ou close
Tout ça, sachant que potentiellement sur 48 niveaux il n'y a aucun indice que l'appel de fonction lèvera une exception en plein milieu de l'algorithme...
Alors apparemment ça semble adapté à ton cas, tant mieux pour toi. Mais je reste attaché à ce que mes fonctions s'exécutent jusqu'à leur unique point de sortie, avec bien sûr une gestion des échecs d'appels aux sous-fonctions.
# Pas de fumée sans feu
Posté par Christophe . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 10.
Il y a sûrement des scénarios où une exception peut faire l'affaire. Mais personnellement, je trouve que le nombre de pièges que ça pose éclipse le gain en lisibilité.
En fait, ce sont essentiellement les mêmes pièges que goto: on perd la maîtrise du flux de la fonction.
Dans ton exemple, une exception est lancée 50 niveau en dessous. Il faut donc, systématiquement, et à chaque étage:
Tout ça, sachant que potentiellement sur 48 niveaux il n'y a aucun indice que l'appel de fonction lèvera une exception en plein milieu de l'algorithme...
Alors apparemment ça semble adapté à ton cas, tant mieux pour toi. Mais je reste attaché à ce que mes fonctions s'exécutent jusqu'à leur unique point de sortie, avec bien sûr une gestion des échecs d'appels aux sous-fonctions.