Redigite a exceção com um tipo e mensagem diferentes, preservando as informações existentes

Estou escrevendo um módulo e quero ter uma hierarquia de exceções unificada para as exceções que ele pode gerar (por exemplo, herdar de uma FooErrorclasse abstrata para todas asfoo exceções específicas do módulo). Isso permite que os usuários do módulo capturem essas exceções específicas e as tratem distintamente, se necessário. Mas muitas das exceções levantadas no módulo são geradas por causa de alguma outra exceção; por exemplo, falha em alguma tarefa devido a um OSError em um arquivo.

O que eu preciso é "agrupar" a exceção capturada, de modo que ela tenha um tipo e mensagem diferentes , para que as informações estejam disponíveis ainda mais na hierarquia de propagação por qualquer que seja a captura da exceção. Mas não quero perder o tipo, a mensagem e o rastreamento de pilha existentes; todas essas informações são úteis para alguém que tenta depurar o problema. Um manipulador de exceção de nível superior não é bom, pois estou tentando decorar a exceção antes que ela avance na pilha de propagação, e o manipulador de nível superior está muito atrasado.

Isso é parcialmente resolvido derivando os footipos de exceção específicos do meu módulo do tipo existente (por exemplo class FooPermissionError(OSError, FooError)), mas isso não facilita a quebra da instância de exceção existente em um novo tipo, nem modifica a mensagem.

PEP 3134 do Python "Encadeamento de exceções e rastreamentos incorporados" discute uma alteração aceita no Python 3.0 para "encadear" objetos de exceção, para indicar que uma nova exceção foi gerada durante o tratamento de uma exceção existente.

O que estou tentando fazer está relacionado: preciso também que ele funcione em versões anteriores do Python, e não para encadeamento, mas apenas para polimorfismo. Qual é a maneira certa de fazer isso?

O Python 3 introduziu o encadeamento de exceções (conforme descrito no PEP 3134 ). Isso permite, ao criar uma exceção, citar uma exceção existente como a "causa":

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

A exceção capturada, assim, se torna parte (é a “causa”) da nova exceção e está disponível para qualquer código que captura a nova exceção.

Ao usar esse recurso, o __cause__atributo é definido. O manipulador de exceção interno também sabe como relatar a "causa" e o "contexto" da exceção junto com o rastreamento.

No Python 2 , parece que este caso de uso não tem uma boa resposta (conforme descrito por Ian Bicking e Ned Batchelder ). Vadio.

Você pode usar sys.exc_info () para obter o rastreamento e criar sua nova exceção com o referido rastreamento (como o PEP menciona). Se você deseja preservar o tipo e a mensagem antigos, pode fazê-lo na exceção, mas isso só será útil se o que detectar a exceção a procurar.

Por exemplo

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

Claro, isso realmente não é tão útil. Se fosse, não precisaríamos desse PEP. Eu não recomendaria fazê-lo.

Você pode criar seu próprio tipo de exceção que estende a exceção que você capturou.

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

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

Mas na maioria das vezes, acho que seria mais simples capturar a exceção, manipulá-la e raisea exceção original (e preservar o retorno) ou raise NewException(). Se eu estivesse chamando seu código e recebesse uma de suas exceções personalizadas, esperaria que seu código já tenha tratado qualquer exceção que você teve que capturar. Portanto, eu não preciso acessá-lo pessoalmente.

Edit: Eu encontrei esta análise de maneiras de lançar sua própria exceção e manter a exceção original. Não há soluções bonitas.

Eu também descobri que muitas vezes eu preciso de algum "empacotamento" para os erros gerados.

Isso incluía o escopo de uma função e, às vezes, quebra apenas algumas linhas dentro de uma função.

Criou um wrapper para ser usado a decoratore context manager:

Implementação

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

Exemplos de uso

decorador

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

ao chamar o dométodo, não se preocupe IndexError, apenasMyError

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

gerenciador de contexto

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

dentro do2, no context manager, se IndexErrorfor levantado, será embrulhado e levantadoMyError

A solução mais direta para suas necessidades deve ser esta:

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

Dessa forma, você pode imprimir sua mensagem posteriormente e o erro específico gerado pela função de upload