Relancer l'exception avec un type et un message différents, en préservant les informations existantes

J'écris un module et je souhaite avoir une hiérarchie d'exceptions unifiée pour les exceptions qu'il peut soulever (par exemple, hériter d'une FooErrorclasse abstraite pour toutes les fooexceptions spécifiques du module). Cela permet aux utilisateurs du module d'attraper ces exceptions particulières et de les gérer distinctement, si nécessaire. Mais la plupart des exceptions levées à partir du module sont déclenchées à cause d'une autre exception; par exemple, échec d'une tâche à cause d'une erreur OSError sur un fichier.

Ce dont j'ai besoin, c'est «d'envelopper» l'exception capturée de telle sorte qu'elle ait un type et un message différents , de sorte que les informations soient disponibles plus haut dans la hiérarchie de propagation par tout ce qui intercepte l'exception. Mais je ne veux pas perdre le type, le message et la trace de pile existants; ce sont toutes des informations utiles pour quelqu'un qui essaie de déboguer le problème. Un gestionnaire d'exceptions de niveau supérieur n'est pas bon, car j'essaie de décorer l'exception avant qu'elle ne monte plus haut dans la pile de propagation, et le gestionnaire de niveau supérieur est trop tard.

Ceci est en partie résolu en dérivant les footypes d'exceptions spécifiques de mon module à partir du type existant (par exemple class FooPermissionError(OSError, FooError)), mais cela ne facilite pas l'encapsulation de l'instance d'exception existante dans un nouveau type, ni ne modifie le message.

Le PEP 3134 de Python «Chaînage d'exceptions et traçages intégrés» traite d'un changement accepté dans Python 3.0 pour le «chaînage» des objets d'exception, pour indiquer qu'une nouvelle exception a été déclenchée lors de la gestion d'une exception existante.

Ce que j'essaie de faire est lié: j'en ai besoin aussi pour les versions antérieures de Python, et j'en ai besoin non pas pour le chaînage, mais uniquement pour le polymorphisme. Quel est le bon moyen de le faire?

Python 3 a introduit le chaînage d'exceptions (comme décrit dans PEP 3134 ). Cela permet, lors de la levée d'une exception, de citer une exception existante comme «cause»:

try:
    frobnicate()
except KeyError as exc:
    raise ValueError("Bad grape") from exc

L'exception interceptée devient ainsi une partie de (est la «cause de») la nouvelle exception, et est disponible pour tout code qui intercepte la nouvelle exception.

En utilisant cette fonctionnalité, l' __cause__attribut est défini. Le gestionnaire d'exceptions intégré sait également comment signaler la «cause» et le «contexte» de l'exception avec le traçage.

Dans Python 2 , il semble que ce cas d'utilisation n'ait pas de bonne réponse (comme décrit par Ian Bicking et Ned Batchelder ). Bummer.

Vous pouvez utiliser sys.exc_info () pour obtenir le traçage, et lever votre nouvelle exception avec ledit traçage (comme le PEP le mentionne). Si vous souhaitez conserver l'ancien type et le message, vous pouvez le faire sur l'exception, mais ce n'est utile que si ce qui intercepte votre exception le recherche.

Par exemple

import sys

def failure():
    try: 1/0
    except ZeroDivisionError, e:
        type, value, traceback = sys.exc_info()
        raise ValueError, ("You did something wrong!", type, value), traceback

Bien sûr, ce n'est vraiment pas si utile. Si c'était le cas, nous n'aurions pas besoin de ce PEP. Je ne recommanderais pas de le faire.

Vous pouvez créer votre propre type d'exception qui étend l'exception que vous avez interceptée.

class NewException(CaughtException):
    def __init__(self, caught):
        self.caught = caught

try:
    ...
except CaughtException as e:
    ...
    raise NewException(e)

Mais la plupart du temps, je pense qu'il serait plus simple d'attraper l'exception, de la gérer et de raisel'exception d'origine (et de conserver le retraçage) ou raise NewException(). Si j'appelais votre code et que je recevais l'une de vos exceptions personnalisées, je m'attendrais à ce que votre code ait déjà géré toute exception que vous avez dû intercepter. Je n'ai donc pas besoin d'y accéder moi-même.

Edit: J'ai trouvé cette analyse des moyens de lever votre propre exception et de conserver l'exception d'origine. Pas de jolies solutions.

J'ai également constaté que plusieurs fois, j'ai besoin d'un "emballage" aux erreurs soulevées.

Cela incluait à la fois la portée d'une fonction et n'enveloppait parfois que quelques lignes à l'intérieur d'une fonction.

Créé un wrapper à utiliser a decoratoret context manager:

la mise en oeuvre

import inspect
from contextlib import contextmanager, ContextDecorator
import functools    

class wrap_exceptions(ContextDecorator):
    def __init__(self, wrapper_exc, *wrapped_exc):
        self.wrapper_exc = wrapper_exc
        self.wrapped_exc = wrapped_exc

    def __enter__(self):
        pass

    def __exit__(self, exc_type, exc_val, exc_tb):
        if not exc_type:
            return
        try:
            raise exc_val
        except self.wrapped_exc:
            raise self.wrapper_exc from exc_val

    def __gen_wrapper(self, f, *args, **kwargs):
        with self:
            for res in f(*args, **kwargs):
                yield res

    def __call__(self, f):
        @functools.wraps(f)
        def wrapper(*args, **kw):
            with self:
                if inspect.isgeneratorfunction(f):
                    return self.__gen_wrapper(f, *args, **kw)
                else:
                    return f(*args, **kw)
        return wrapper

Exemples d'utilisation

décorateur

@wrap_exceptions(MyError, IndexError)
def do():
   pass

lors de l'appel de la dométhode, ne vous inquiétez pas IndexError, justeMyError

try:
   do()
except MyError as my_err:
   pass # handle error 

gestionnaire de contexte

def do2():
   print('do2')
   with wrap_exceptions(MyError, IndexError):
       do()

à l'intérieur do2, dans le context manager, siIndexError est soulevé, il sera enveloppé et soulevéMyError

La solution la plus simple à vos besoins devrait être la suivante:

try:
     upload(file_id)
except Exception as upload_error:
     error_msg = "Your upload failed! File: " + file_id
     raise RuntimeError(error_msg, upload_error)

De cette façon, vous pouvez imprimer ultérieurement votre message et l'erreur spécifique générée par la fonction de téléchargement