tordu: aucune trace d'exception en cas d'erreur d'un rappel

Question

Considérez le code suivant:

df = defer.Deferred()
def hah(_): raise ValueError("4")
df.addCallback(hah)
df.callback(hah)

Quand il fonctionne, cette exception se mange juste. Où est-il allé? Comment puis-je obtenir à afficher? Faire defer.setDebugging(True) n'a pas d'effet.

Je pose cette question parce que d'autres fois, je reçois une impression disant « erreur non gérée dans Différé: ». Comment puis-je obtenir que cela se produise dans ce cas? Je vois que si j'ajouter un errback à df alors la errback est appelée à l'exception, mais tout ce que je veux faire est d'imprimer l'erreur et ne rien d'autre, et je ne veux pas ajouter manuellement ce gestionnaire à chaque différé je crée .

Answer 1

L'exception est toujours assis dans le différé. Il y a deux résultats possibles à ce stade:

• Vous pouvez ajouter un errback au différé. Dès que vous le faites, il sera appelé à un échec contenant l'exception qui a été soulevée.
• Vous pourriez laisser les ordures collectées soit différée (df explicitement suppression, ou le retour de la fonction, ou perdre la référence de toute autre manière). Cela déclenche la « » erreur non gérée dans Différé « code ».

Parce qu'un errback peut être ajouté à un différé à tout moment (soit le premier point ci-dessus), Deferreds ne font rien d'erreurs sinon non gérées tout de suite. Ils ne savent pas si l'erreur est vraiment Unhandled, ou tout simplement Unhandled jusqu'à présent. Il est seulement lorsque le différé est nettoyé qu'il peut être sûr que personne d'autre va gérer l'exception, de sorte que ce quand il est connecté.

En général, vous voulez être sûr que vous avez errbacks sur Deferreds, précisément parce qu'il est parfois difficile de prédire quand un différé sera obtenir les déchets collectés. Il pourrait être une longue période, ce qui signifie qu'il pourrait être longtemps avant que vous en apprendre davantage sur l'exception si vous ne possédez pas votre propre attaché errback.

Cela ne doit pas être un terrible fardeau. Tout différé (a) qui est de retour d'un rappel sur un autre différé (b) (lorsque l'enchaînement se produit) passera ses erreurs le long de b. Donc (a) n'a pas besoin de errbacks supplémentaires à ce sujet pour l'enregistrement et les rapports, que (b) le fait. Si vous avez une seule tâche logique qui est compliquée et implique de nombreuses opérations asynchrones, il est presque toujours le cas que tous les Deferreds impliqués dans ces opérations devraient canaliser leurs résultats (succès ou échec) à un principal différé qui représente l'opération logique. Vous souvent besoin des comportements de gestion des erreurs spéciales sur celui différé, et qui vous permettra de gérer les erreurs de l'un des autres Deferreds impliqués.