Salut,

restreignons la discussion à Python, si ça peut changer quelque chose.

J'ai un problème avec les exceptions. Il me semble que dans beaucoup de cas, voir quasi-tous, une bonne vérification des données suffit à ne pas avoir besoin d'exception.

Par exemple:

def multiply_entropy(n):
if n == 0:
return 0.
else:
return n * log(n)

vaut mieux que:

def multiply_entropy(n):
try:
result = n * log(n)
except <le_nom_de_lexception_je_men_souviens_plus>:
result = 0
return result

Dites-moi dans quels cas une vérification "manuelle" des données n'est pas préférable à une gestion des exceptions. Je ne comprend pas.

Salut,

Sémantiquement, les exceptions devraient être gérées pour ce qu'elles sont : des erreurs _exceptionnelles_. Par conséquent, si c'est pour vérifier un input utilisateur, une vérification manuelle peut mieux convenir, puisque tu sais que c'est probable.

À côté, prenons l'exemple d'une connexion à un serveur : tu ne maîtrises pas toutes les conditions nécessaires à la réussite de ton bout de code : des erreurs peuvent arriver ou ne pas arriver, et t'as pas vraiment moyen de le savoir. Il est donc judicieux d'utiliser ici des exceptions, qui se chargent de récupérer les éventuelles erreurs de serveur indisponible ou timeout pour retourner un message type 'Serveur indisponible'.

La limite est assez floue, mais moi je considère, en règle générale, que si on peut facilement prévoir l'erreur et ses conditions, et/ou si on a un input utilisateur, on vérifie manuellement. Le cas contraire, on prévoit de la récupération d'exceptions.

En pratique, les exceptions peuvent être bien utiles pour avoir à écrire moins de code dans certaines conditions, alors on trouve aussi souvent des récupérations 'fourre-tout' dans des cas où de la vérification manuelle aurait semblé plus logique. Mais ça après...

Parfois tu as aussi besoin d'utiliser des exceptions là où tu sais pourtant le genre d'erreur qu'il peut y avoir, pour les rediriger, si t'as besoin de log ou d'afficher des messages d'erreur dans une application avec UI par exemple.

Conchoide -> Pourquoi retourner 0 et propager une erreur ? Tu cours le risque qu'au mieux ça plante ailleurs et qu'il faille remonter la piste en déboguant, au pire que ça passe inaperçu, jusqu'au jour où...

La bonne idée serait plutôt (pseudo-code, je n'ai plus Python en tête):

def multiply_entropy(n):
if n == 0:
throw Exception("multiply_entropy cannot be called with 0");
else:
return n * log(n)

Ainsi on fail-fast et on sait exactement où et quoi. Et au besoin, on l'intercepte de façon générale dans la boucle d'interaction avec l'utilisateur, on affiche l'erreur et on récupère.

Je suis d'accord avec Mjonir, la pire gestion d'erreur possible, c'est justement de renvoyer une valeur par défaut en jetant l'exception sous le tapis.

Avec les exceptions bien utilisées, tu peux centraliser ta gestion d'erreur de façon très propre. Le problème c'est que beaucoup de gens pensent qu'un "throw" doit être impérativement suivi d'un "catch" alors qu'une bonne architecture voudrait plutôt que le "catch" ait lieu dans les couches supérieures (code UI, initiateur de traitement, etc...).

Merci pour vos réponses.

Mjonir et _skip :

"Conchoide -> Pourquoi retourner 0 et propager une erreur ? Tu cours le risque qu'au mieux ça plante ailleurs et qu'il faille remonter la piste en déboguant, au pire que ça passe inaperçu, jusqu'au jour où... "

L'exemple que j'ai choisi possède un caractère particulier, peut-être que j'aurais dû mieux préciser ça.
La limite de n*log(n) pour n tendant vers 0 n'est pas indéfinie, mais elle vaut zero. Ce n'est pas une erreur si ma fonction renvoie 0, c'est tout-à-fait voulu. POURTANT, la fonction log, du point de vue informatique, va renvoyer une erreur lorsqu'elle prendra zero en argument, ce qui est normal, car elle ne sait pas que je suis en train de faire une limite. D'où mon exemple : on ne peut pas utiliser la formule n * log(n) pour implémenter la limite. Il faut soit traiter l'input n, soit utiliser les exceptions.

python est plus EAFP[1] que LBYL[2], je dirai même que c'est carrément du exception oriented programming, celle ci sont utilisées pour contrôler le flot d’exécution. par exemple, les itérateurs s’arrêtent avec une exception[3].

for i in range(10):
    [...]

c'est pareil que

it = iter(range(10))
while(True):
    try:
        i = next(it)
        [...]
    except StopIteration:
        break

[1] https://docs.python.org/3rg/3.5/glossary.html#term-eafp
[2] https://docs.python.org/3rg/3.5/glossary.html#term-lbyl
[3] https://docs.python.org/3.5/library/exceptions.html#StopIteration
https://docs.python.org/3.5/library/stdtypes.html#typeiter