Ponownie zgłoś wyjątek z innym typem i komunikatem, zachowując istniejące informacje

Piszę moduł i chcę mieć ujednoliconą hierarchię wyjątków dla wyjątków, które może on wywołać (np. Dziedziczenie z FooErrorklasy abstrakcyjnej dla wszystkich foowyjątków specyficznych dla modułu). Pozwala to użytkownikom modułu na wychwycenie tych wyjątków i wyraźną obsługę ich w razie potrzeby. Ale wiele wyjątków zgłoszonych z modułu jest zgłaszanych z powodu innego wyjątku; np. niepowodzenie w wykonaniu jakiegoś zadania z powodu błędu OSError w pliku.

To, czego potrzebuję, to „zawinąć” przechwycony wyjątek w taki sposób, aby miał inny typ i inny komunikat , aby informacje były dostępne na wyższych poziomach hierarchii propagacji przez wszystko, co przechwytuje wyjątek. Ale nie chcę stracić istniejącego typu, komunikatu i śladu stosu; to wszystko jest przydatne dla kogoś, kto próbuje debugować problem. Obsługa wyjątków najwyższego poziomu nie jest dobra, ponieważ próbuję udekorować wyjątek, zanim przejdzie dalej w górę stosu propagacji, a program obsługi najwyższego poziomu jest za późno.

Jest to częściowo rozwiązane poprzez wyprowadzenie foospecyficznych typów wyjątków mojego modułu z istniejącego typu (np. class FooPermissionError(OSError, FooError)), Ale to nie ułatwia pakowania istniejącego wystąpienia wyjątku w nowy typ ani modyfikowania komunikatu.

Python PEP 3134 „Exception Chaining and Embedded Tracebacks” omawia zmianę zaakceptowaną w Pythonie 3.0 dla „łańcuchowego” obiektów wyjątków, aby wskazać, że nowy wyjątek został zgłoszony podczas obsługi istniejącego wyjątku.

To, co próbuję zrobić, jest powiązane: potrzebuję tego również we wcześniejszych wersjach Pythona i nie potrzebuję go do tworzenia łańcuchów, a tylko do polimorfizmu. Jaki jest właściwy sposób, aby to zrobić?

Python 3 wprowadził łańcuch wyjątków (zgodnie z opisem w PEP 3134 ). Dzięki temu podczas zgłaszania wyjątku można zacytować istniejący wyjątek jako „przyczynę”:

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

W ten sposób przechwycony wyjątek staje się częścią (jest „przyczyną”) nowego wyjątku i jest dostępny dla każdego kodu przechwytującego nowy wyjątek.

Korzystając z tej funkcji, __cause__ustawiany jest atrybut. Wbudowana procedura obsługi wyjątków wie również, jak zgłosić „przyczynę” i „kontekst” wyjątku wraz ze śledzeniem.

W Pythonie 2 wydaje się, że ten przypadek użycia nie ma dobrej odpowiedzi (jak opisali Ian Bicking i Ned Batchelder ). Porażka.

Możesz użyć sys.exc_info (), aby uzyskać śledzenie i zgłosić nowy wyjątek za pomocą wspomnianego śledzenia (jak wspomina PEP). Jeśli chcesz zachować stary typ i wiadomość, możesz to zrobić na wyjątku, ale jest to przydatne tylko wtedy, gdy szuka go cokolwiek, co wyłapuje twój wyjątek.

Na przykład

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

Oczywiście to naprawdę nie jest przydatne. Gdyby tak było, nie potrzebowalibyśmy tego PEP. Nie polecałbym tego robić.

Możesz utworzyć własny typ wyjątku, który rozszerza każdy wychwycony wyjątek .

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

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

Ale przez większość czasu myślę, że łatwiej byłoby złapać wyjątek, obsłużyć go i albo raiseoryginalny wyjątek (i zachować śledzenie), albo raise NewException(). Gdybym wywoływał twój kod i otrzymałem jeden z twoich niestandardowych wyjątków, spodziewałbym się, że twój kod już obsłużył każdy wyjątek, który musiałeś złapać. Dlatego nie muszę sam uzyskiwać do niego dostępu.

Edycja: znalazłem tę analizę sposobów zgłaszania własnego wyjątku i zachowania oryginalnego wyjątku. Żadnych ładnych rozwiązań.

Zauważyłem też, że wiele razy potrzebuję „zawijania” podniesionych błędów.

Obejmuje to zarówno zakres funkcji, jak i czasami zawija tylko niektóre linie wewnątrz funkcji.

Utworzono opakowanie do użycia a decoratori context manager:

Realizacja

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

Przykłady użycia

dekorator

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

podczas wywoływania dometody nie martw się IndexError, po prostuMyError

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

menedżer kontekstu

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

wewnątrz do2, context managerjeśli IndexErrorzostanie podniesiony, zostanie zawinięty i podniesionyMyError

Najbardziej prostym rozwiązaniem dla Twoich potrzeb powinno być:

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

W ten sposób możesz później wydrukować swoją wiadomość i określony błąd wyrzucony przez funkcję wysyłania