Et deux petites coquilles :

Parce que c’est la manière de faire que de la communauté

elles sont au coeur du fonctionnement du langage, et pas juste pour pour les erreurs.

Ce que t’expliques pour les exceptions qui sont au coeur de python, marche aussi pour le logging qui y est intégré.

Écrire print() pour loguer en python c’est contre l’esprit du langage.

En fait, quand tu débarques dans un langage, il y a tous les non dits et les usages de la “communauté” qui ne sont pas explicites.

Donc non seulement faut apprendre le langage mais aussi les bonnes pratiques de la communauté.

C’est tout l’intérêt de ce blog qui explique bien l’esprit du langage.

J’ai réécrit une bonne partie de mon code python après la lecture de ce blog.

Par rapport au premier exemple, j’aurais tendance à le faire de 2 manières différentes en fonction du contexte :

Si j’ai absolument besoin d’un (et un seul) retour, ma fonction sera get_element() et lèvera une exception si l’element n’existe pas. Sinon, c’est seulement une recherche qui peut ne rien trouver, et la fonction sera find_element() ou search_element(), et ça retournera None si je cherche un seul element, ou un iterable vide si je peux avoir plusieurs elements (find_elements()). Dans ce cas, c’est la fonction appelante qui se chargera de lever une exception si l’absence de retour est finalement problématique.

Ce que je veux dire, c’est que python n’a pas trouvé de recette magique pour que les exceptions deviennent miraculeusement rapide dans l’absolu.

Le Fail Fast consiste à ne pas traiter des situations qui ne devraient pas arriver. Par exemple, il ne faut pas tester à null à chaque fois qu’un objet est passé en paramètre. Ou il ne faut pas vérifier si un entier est toujours positif lorsqu’on passe un index de tableau.

Il faut au contraire ne rien faire. Ca plantera si un null ou un entier négatif arrive. Mais si ça plante, ce n’est pas le code de traitement du null ou de l’entier qui bug, c’est avant. Un mauvais paramètre aura été passé et il faut en trouver la raison.

Le fail fast permet de ne pas surcharger le code avec de la verbosité qui ne fera que rendre la correction de bug plus complexe encore.

Au pire amène toi sur indexerror pour cette question, le format s’y prête beaucoup plus, de même que la qualité des réponses.

On pourra en discuter tranquillement histoire de laisser la place ici pour les com’s un peu moins précis/techniques :)

Le cas d’usage c’est un truc de ce gout la:

# On lance un thread qui bloque sur le fd d'une socket, et remplit ReadThread.data_received avec les donnees lues.

read_thread = ReadThread(socket_fd)

read_thread.start()

# Si on n'a pas reçu les trames de demarrage au bout de 5 secondes

sleep(5)

if read_thread.data_received != "StartMessage":

    raise StartDatasException

while True:

    read_thread.data_received = None

    sleep(5)

    # Si on n'a pas reçu le heartbeat au bout de 5 secondes

    if read_thread.data_received != "Heartbeat":

        raise HeartBeatException

Comment gérer l’arrêt du thread, la fermeture de la socket… de maniere unifiee pour les 2 raise d’exception ?

Bon l’exemple est rapide et pourri de bugs potentiels, mais ce qui m’intéressesse en l’occurence c’est surtout le nettoyage des données suite aux raise