Intercepter une exception au bon niveau

Une dépense invalide doit être refusée, mais un traceback complet n’est généralement pas adapté à la personne qui utilise le programme. Vous allez laisser l’erreur remonter depuis la fonction métier, puis la traiter au point d’entrée pour afficher une explication claire sans faire passer l’exécution pour une réussite.

Laisser l’erreur remonter jusqu’au bon niveau

Dans la leçon précédente, vous avez défini les préconditions de total_depenses et fait lever TypeError ou ValueError lorsqu’un montant est invalide. La fonction métier ne devrait pas décider comment présenter cette erreur à l’écran : elle signale le problème en levant une exception, et le point d’entrée choisit quoi faire pour l’utilisateur.

Une exception non interceptée remonte les appels qui l’ont déclenchée jusqu’à ce qu’un bloc try avec un except correspondant la prenne en charge. Cette remontée s’appelle la propagation de l’exception. Interceptez-la là où vous pouvez apporter une réponse utile : ici, dans main.py, qui orchestre l’exécution et peut afficher un message compréhensible.

Encadrer le calcul dans le point d’entrée

Conservez la validation dans transactions.py et placez le traitement autour de l’appel à cette fonction dans main.py. L’exemple ci-dessous reprend les deux dépenses du projet. Le bloc except ne vise que les deux erreurs que la fonction peut lever pour ces préconditions : les autres erreurs inattendues ne sont donc pas dissimulées.

# depenses/transactions.py

def total_depenses(transactions):
    total = 0.0
    for montant in transactions:
        if isinstance(montant, bool) or not isinstance(montant, (int, float)):
            raise TypeError("Chaque montant doit être numérique.")
        if montant <= 0:
            raise ValueError("Chaque montant doit être strictement positif.")
        total += montant
    return total

# depenses/main.py
import sys

from depenses.transactions import total_depenses


def main():
    transactions = [42.80, 18.50]
    try:
        total = total_depenses(transactions)
    except (TypeError, ValueError) as erreur:
        print(f"Impossible de calculer les dépenses : {erreur}")
        sys.exit(1)

    print(f"Total des dépenses : {total:.2f} EUR")


if __name__ == "__main__":
    main()

Total des dépenses : 61.30 EUR

Le programme reste lancé comme dans la leçon sur le point d’entrée : python -m depenses.main. Si vous remplacez temporairement le premier montant par 0, total_depenses lève une ValueError, qui remonte à main. Vous obtenez alors le message prévu et le programme se termine avec le code de sortie 1, indicateur d’échec pour le système ou un script qui lance le programme.

Distinguer une erreur utilisateur d’un succès

Le message présenté dans l’exemple reprend le texte de l’exception et ajoute le contexte de l’opération qui a échoué. Il aide à comprendre pourquoi le calcul n’a pas abouti, sans afficher la pile d’appels destinée au diagnostic technique. Lorsqu’une erreur est interceptée, pensez aussi à la suite du programme : ici, sys.exit(1) empêche l’affichage d’un total et signale explicitement l’échec.

Le bloc try doit rester ciblé sur les instructions susceptibles de produire les erreurs que vous savez traiter. Dans cet exemple, il entoure seulement le calcul : si vous ajoutiez d’autres opérations sans rapport dans ce bloc, une exception inattendue pourrait être présentée à tort comme une erreur de montant. Plus tard, le même principe vous aidera à traiter proprement les problèmes liés à l’import de fichiers ou à l’API, au niveau où vous pouvez en informer l’utilisateur.

À retenir

• Laissez la fonction métier signaler une donnée invalide en levant l’exception appropriée.
• L’exception se propage jusqu’au premier bloc `except` capable de la traiter.
• Interceptez seulement les erreurs attendues, au niveau où vous pouvez agir ou informer l’utilisateur.
• Affichez un message utile et signalez l’échec avec un code de sortie non nul, plutôt que de poursuivre comme si le calcul avait réussi.