Обработка исключений Мы хотим, чтобы наши программы работали | Советы разработчикам (python и не только)

Обработка исключений

Мы хотим, чтобы наши программы работали стабильно, и необработанные исключения - одно из проявлений нестабильности. При этом мы так же хотим, чтобы программы работали предсказуемо, не портили данные и не содержали логических ошибок.

Говоря о каждой конкретной строке кода можно выделить два вида исключений:
* ожидаемые (возможные) - исключения, которые мы предполагаем, что могут возникнуть в данном месте, и знаем какие действия принимать в этой ситуации
* неожиданные - исключения, которые не должны были возникнуть в этом месте, но возникли из-за неверно написанного кода и мы не имеем стратегии поведения в этой ситуации


Отсюда следуют следующие советы:
1. Всегда указывайте исключение, которое вы ловите. Если вы не знаете, что за исключение может возникнуть - вы не знаете корректно ли обрабатывать его вашим способом.
2. Указывайте максимально конкретный класс исключения.
3. Оборачивайте в try/except наименьший возможный код. Если требуется - разбивайте его на несколько выражений
4. Обрабатывайте исключения именно там, где у вас достаточно информации для принятия решения, что делать в данной ситуации.


Частой ошибкой новичков бывает написать просто except: или except Exception - не делайте так.
* Обработка всех подряд исключений, как правило, вообще не корректна, так как туда входит, например, KeyboardInterrupt, по которому ожидается как раз завершение программы. Но это допустимо, если после такой обработки вы пробросите исключение дальше.
* Обработка же Exception актуальна на уровне фреймворка, когда у нас есть стандартный способ реакции на неизвестные ошибки - выдача клиенту ответа с кодом 500, повтор обработки сообщения из очереди т.п.

Другая распространенная ошибка - поймать исключение и заменить его на возврат специального значения. В некоторых случаях это допустимо, но зачастую таким образом мы просто меняем способ доставки информации о наличии исключительной ситуации вызывающему коду, что приводит к появлению дополнительного кода, не делающего реальной работы, а только занимающегося пробросом ошибки вверх по стеку. Это применимо в других языках программирования, но в питоне обычно используется механизм исключений.

Говоря о реализации адаптеров для различных сервисов или БД хорошей идеей будет ввести свои классы исключений

* Реализуя адаптер мы хотим скрыть детали реализации. Например, мы реализовали класс, реализующий хранение определенных сущностей в БД. Затем после очередного рефакторинга мы вынесли это в отдельный микросервис. Интерфейс адаптера при этом не изменился и мы ожидаем что использующий такой адаптер код не будет меняться. И если исключения вроде OSError или ValueError достаточно нейтральны и почти не говорят о реализации, то классы исключения, принадлежащие конкретной используемой библиотеки не стоит прокидывать извне такого адаптера.

* Вторая причина для введения своих классов исключений - изменение детализации. С одной стороны, разные сторонние исключения могут означать одну ошибку с точки зрения нашей логики (как например, разные виды сетевых ошибок могут означать просто недоступность внешнего сервиса). С другой - наоборот, возникновение исключения одного типа в разных местах кода адаптера может означать разное для вызывающего кода.

Дополнительные материалы:
* https://martinfowler.com/articles/replaceThrowWithNotification.html
* https://peps.python.org/pep-0008/#programming-recommendations