Как правило, вы должны «ловить» исключения, которые вы ожидаете (потому что они могут быть вызваны ошибкой пользователя или другими проблемами среды, не зависящими от вашей программы), особенно если вы знаете, что ваш код может сделать делать с ними Простое указание большего количества деталей в отчете об ошибках является незначительной проблемой, хотя в некоторых программах это может потребоваться (например, на долговременном сервере, который не должен аварийно завершать работу из-за таких проблем, а скорее регистрировать много информации о состоянии, дать используйте краткое объяснение и продолжайте работать над будущими запросами).
NameError, TypeError, KeyError, ValueError, SyntaxError, AttributeError и т. Д. Могут рассматриваться как ошибки в программе - ошибки, а не проблемы вне управление программистом. Если вы выпускаете библиотеку или фреймворк, так что ваш код будет вызываться другим кодом, находящимся вне вашего контроля, то вполне вероятно, что такие ошибки могут быть в этом другом коде; обычно вы должны позволить распространению исключения, чтобы помочь другому программисту отлаживать свои собственные ошибки. Если вы выпускаете приложение, у вас есть ошибки, и вы должны выбрать стратегию, которая поможет вам их найти.
Если ваши ошибки обнаруживаются, когда конечный пользователь запускает программу, вы должны зарегистрировать много информации о состоянии и дать пользователю краткое объяснение и извинения (возможно, с просьбой выслать вам информацию журнала, если вы не может автоматизировать это - или, по крайней мере, спросить разрешение, прежде чем отправлять что-либо с компьютера пользователя на ваш). Возможно, вам пока удастся сохранить часть работы пользователя, но часто (в программе, которая, как известно, глючит), которая может не работать в любом случае.
Большинство ошибок должно появляться во время вашего собственного тестирования; в этом случае распространение исключения является полезным, поскольку вы можете подключить его к отладчику и изучить детали ошибки.
Иногда некоторые исключения, подобные этим, появляются просто потому, что «проще просить прощения, чем разрешения» (EAFP) - вполне приемлемый метод программирования в Python. В этом случае, конечно, вы должны обращаться с ними сразу. Например:
try:
return mylist[theindex]
except IndexError:
return None
здесь можно ожидать, что theindex, как правило, является допустимым индексом для mylist, но иногда выходит за пределы mylist - и в последнем случае, по семантике гипотетического приложения, к которому относится этот фрагмент , это не ошибка, просто небольшая аномалия, которую нужно исправить, считая, что список концептуально расширен с обеих сторон бесконечными числами None с. Проще просто попробовать / исключить, чем правильно проверить положительные и отрицательные значения индекса (и быстрее, если выход за пределы является действительно редким явлением).
Аналогично соответствующие случаи для KeyError и AttributeError происходят реже, благодаря встроенным методам getattr и get dicts (которые позволяют указывать значение по умолчанию), collections.defaultdict и т. Д .; но списки не имеют прямого эквивалента таковым, поэтому попытка / исключение встречается чаще для IndexError.
Попытка перехвата синтаксических ошибок, ошибок типов, ошибок значений, именных ошибок и т. Д. Немного реже и более противоречива - хотя, безусловно, было бы целесообразно, если бы ошибка была диагностирована в «плагине», третье сторонний код вне вашего контроля, который ваша платформа / приложение пытается загрузить и выполнить динамически (действительно, это тот случай, когда вы предоставляете библиотеку или тому подобное и вам нужно мирно сосуществовать с кодом вне вашего контроля, который вполне может быть ошибочным). Ошибки типа и значения могут иногда встречаться в шаблоне EAFP - например, когда вы пытаетесь перегрузить функцию, чтобы принять строку или число и вести себя немного по-разному в каждом случае, обнаружение таких ошибок может быть лучше, чем попытка проверки типов - но сама концепция перегруженных функций чаще, чем не совсем сомнительны.
Возвращаясь к «ошибкам пользователя и среды», пользователи неизбежно будут совершать ошибки, когда будут вводить данные, указывать имя файла, которого на самом деле нет (или что у вас нет разрешения на чтение или запись, если это то, что вы ». и так далее: все такие ошибки, конечно же, должны быть обнаружены и привести к четкому объяснению пользователю о том, что пошло не так, и еще один шанс сделать правильный ввод. Иногда сети выходят из строя, базы данных или другие внешние серверы могут не реагировать должным образом и т. Д. - иногда стоит уловить такие проблемы и повторить попытку (возможно, после небольшого ожидания - возможно, с указанием пользователю о том, что не так, например, они возможно, случайно отключил кабель, и вы хотите дать им возможность исправить ситуацию и сказать, когда следует попробовать еще раз), иногда (особенно в автоматических долго работающих программах) вы ничего не можете сделать, кроме упорядоченного выключения (и подробного ведения журнала). каждого возможного аспекта окружающей среды).
Итак, вкратце, ответ на заглавие вашего вопроса: «это зависит» ;-). Я надеюсь, что мне было полезно перечислить многие ситуации и аспекты, от которых это может зависеть, и рекомендовать, какое в целом отношение к таким вопросам является наиболее полезным.