Dla mnie, używając try-except w tym samym zakresie, w którym użyto if-else, nie zyskuje czytelności. Wartością wyjątków jest to, że mogą one zostać przechwycone na wyższym poziomie w drzewie wywołań.
Poruszanie się tylko jeden poziom, unikamy oświadczenie break
:
import glob, os
try:
for file in glob.glob("\\*.txt"):
with open(file) as fp:
# do something with file
except IOError:
print("could not read", file)
Ale prawdziwy geniusz wyjątków jest, gdy kod po prostu znika:
# Operate on several files
# SUCCESS: Returns None
# FAIL: Raises exception
def do_some_files():
for file in glob.glob("\\*.txt"):
with open(file) as fp:
# do something with file
Teraz jest odpowiedzialność programu wywołującego wyświetlać przydatny komunikat o błędzie po awarii. Usunęliśmy odpowiedzialność za uporanie się z awarią całkowicie poza tym kodem i całą inną dziedziną.
W rzeczywistości można całkowicie przenieść odpowiedzialność z naszego programu i do tłumacza. W takim przypadku interpreter wyświetli kilka przydatnych komunikatów o błędach i zakończy nasz program. Jeśli domyślny komunikat Pythona jest wystarczająco dobry dla użytkowników, nie zaleca się sprawdzania błędów w ogóle. Tak więc, oryginalny scenariusz staje:
import glob, os
for file in glob.glob("\\*.txt"):
# Do something
można spróbować otwarcie pliku do odczytu i przechwytywanie wynikowego wyjątku (jeśli istnieje). Byłoby to również bardziej niezawodne niż obecne podejście, ponieważ plik może stać się nieczytelny (lub nawet zniknąć) między dwoma wywołaniami "os.access()". –
Czy rzeczywiście czytasz plik w sekcji "#Do wykonania czegoś" lub czy chcesz tylko sprawdzić jego czytelność? –
@ PM2Ring Właściwie to czytam tam plik. –