2015-10-19 12 views
5

Zastanawiam się, czy można ponownie podnieść (specyficzny) złapany wyjątek i go złapać przez późniejszy (ogólny) z wyjątkiem tego samego try-wyjątkiem. Jako przykład, chcę zrobić coś z konkretnym IOError, ale jeśli nie jest to oczekiwane IOError to wyjątek powinien być traktowany jak każdy inny błąd. To, co początkowo wypróbowałem:Python 'except' fall-through

try: 
    raise IOError() 
except IOError as ioerr: 
    if ioerr.errno == errno.ENOENT: 
     # do something with the expected err 
    else: 
     # continue with the try-except - should be handled like any other error 
     raise 
except Exception as ex: 
    # general error handling code 

Jednak to nie działa: podniesienie powoduje ponowne zgłoszenie wyjątku poza kontekstem try-except. Jaki byłby pythonic sposób pisania tego, aby uzyskać pożądany wyjątek "fall-through" zachowanie?

(jestem świadomy było proponowane „warunkowe z wyjątkiem”, który nie został zrealizowany, co może już rozwiązać ten)

+1

Więc chcesz móc przejść z bloku 'except IOError' do bloku' except Exception'? O ile mi wiadomo, że nie jest to możliwe, tylko jeden blok 'except '(lub blok' else' działa dla danego 'try'. Możesz owijać całość w innym 'try', usuwając wewnętrzny' except Exception', który oznaczałby wszystkie oprócz specjalnie obsługiwanego 'IOError's kończy się w zewnętrznym' try' '' except's. – jonrsharpe

+0

To jest to, co chcę zrobić, i obawiałem się, że tylko jeden z wyjątkiem będzie możliwy. Mam nadzieję na bardziej eleganckie rozwiązanie, takie jak np. Zagnieżdżanie/duplikowanie kodu. – OverlordAlex

Odpowiedz

1

Nie jestem ekspertem w pisaniu pythonically, ale myślę, że jeden oczywisty podejście (jeśli wiesz, że czekasz jeden szczególny rodzaj wyjątku), byłoby użyć zagnieżdżonego obsługę wyjątków:

try: 
    try: 
     raise IOError() 
    except IOError as ioerr: 
     if ioerr.errno == errno.ENOENT: 
      # do something with the expected err 
     else: 
      # pass this on to higher up exception handling 
      raise 

except Exception as ex: 
    # general error handling code 

wiem w swoim komentarzu, że nie ma zagnieżdżonych innego - nie wiem jeśli obsługa wyjątków zagnieżdżonych jest w twojej książce tak zła, ale przynajmniej możesz uniknąć duplikowania kodu.

+0

To świetne podejście, wydaje się oczywiste, gdy już je zobaczysz. Bardzo fajny pomysł! – iFreilicht

1

Tak, pracuję nad tym samym tutaj, a po przejrzeniu dostępnych rozwiązań, zamierzam pójść z wyłapaniem wyjątku nadrzędnego, a następnie przetestować pod kątem szczegółów. W moim przypadku pracuję z modułem dns.

Powiązane problemy