error_processing.py

# # Глава 1. Обработка ошибок (тезисно)
#
# ## Основная идея
#
# * Обработка ошибок — это часть качества кода, а не
# внешнее
# дополнение.
# * Чистый код делает ошибки понятными, предсказуемыми и
# удобными для обработки.
#
# ## Используйте исключения, а не коды возврата
#
# * Коды возврата засоряют бизнес-логику.
# * Исключения позволяют отделить нормальный поток выполнения
# от обработки ошибок.
# * Код становится короче и читабельнее.
#
# ## Не возвращайте `None` или `False` вместо ошибки
#
# * Скрытые ошибки приводят к трудноуловимым
# багам.
# * Лучше явно выбрасывать исключение.
# * Ошибка должна быть заметна сразу.
#
# ## Создавайте собственные исключения
#
# * Именованные исключения лучше, чем общий
# `Exception`.
# * Собственные исключения передают контекст
# ошибки.
# * Упрощается отладка и логирование.
#
# ## Не перехватывайте общие исключения без необходимости
#
# * `except Exception` скрывает реальные проблемы.
# * Перехватывайте только те исключения, которые действительно
# можете обработать.
#
# ## Сообщения об ошибках должны быть информативными
#
# * Сообщение должно объяснять, ЧТО произошло и
# ПОЧЕМУ.
# * Избегайте пустых и абстрактных
# формулировок.
#
# ## Не перегружайте код `try/except`
#
# * Блок `try` должен быть минимальным.
# * Основную логику выносите в отдельные
# функции.
#
# ## Не игнорируйте ошибки
#
# * Пустые `except` — плохая практика.
# * Если ошибку нельзя обработать, её нужно
# пробросить выше.
#
# ## `print` vs `logging`
#
# * `print` не подходит для продакшн-кода.
# * Используйте `logging` с уровнями
# (`info`, `warning`, `error`).
#
# ## Итог
#
# * Чистая обработка ошибок = надёжный и читаемый код.
# * Ошибки должны быть явными, понятными и локализованными.
# * Чем меньше хаотичных `try/except`, тем чище архитектура.
#