Comment décidez-vous où attraper les exceptions et quoi en faire ?

N'attrapez une exception que là où vous pouvez réellement agir : réessayer, substituer une valeur par défaut, ou la traduire en erreur métier avec du contexte. Partout ailleurs, laissez-la remonter jusqu'à une frontière unique qui journalise et renvoie une réponse. Attrapez des types précis plutôt qu'un except nu, n'avalez jamais en silence, et utilisez raise from pour que la cause d'origine survive dans la traceback.

Par défaut je laisse remonter. Un try except n'est justifié que si je peux réessayer, me rabattre sur quelque chose de sensé, ou ajouter du contexte utile à l'appelant. Sinon je ne fais que cacher de l'information. Dans les services, je structure cela comme une frontière d'erreur unique, en général un middleware ou un gestionnaire d'exceptions, qui journalise la traceback complète avec un identifiant de requête et renvoie une réponse propre, et le code en dessous reste lisible parce qu'il n'est pas tapissé de handlers. À l'intérieur d'un module, j'attrape des types étroits et je les traduis en exception métier avec raise from, pour que la traceback garde la cause d'origine, puisque perdre cette chaîne, c'est finir devant une pile d'appels qui ne commence nulle part d'utile. L'except nu est banni dans les bases de code que je pilote, parce qu'il avale aussi KeyboardInterrupt et SystemExit. La distinction à laquelle je tiens le plus, c'est échec attendu contre bug. Un timeout sur une API tierce est attendu et se réessaie. Un KeyError sur mon propre dictionnaire est un bug et doit faire du bruit.