Всем привет!
Объясните, пожалуйста, поподробнее, в каких случаях хорошим стилем является генерация исключения при ошибке, а в каких возвращение кода ошибки с помощью return.
Сейчас пользуюсь и тем и другим, но какой-то четко сформированной методики нет и периодически меня это мучает…
Полная версия: Возвращение и обработка ошибок (return vs. raise)
Если посмотреть на исходники всяких проектов, то там повсеместно используется исключения, как стандартные, так и самописанные для персональных случаев. И это более практикуемый подход, даже более питонячий.
Код ошибки возвращается при аварийном завершении работы программы - это UNIX way.
Код ошибки возвращается при аварийном завершении работы программы - это UNIX way.
JOHN_16
Если посмотреть на исходники всяких проектов, то там повсеместно используется исключения, как стандартные, так и самописанные для персональных случаев. И это более практикуемый подход, даже более питонячий.
Я тоже перехватываю стандартные и свои пишу.
Но окончательно со стилем пока не определился.
Интересно, есть какие-нибудь общие рекомендации по стилю генерации и обработки исключений в Питоне?
Допустим, имеем несколько вложенных вызовов функций, функция каждого уровня может генерировать свои исключения.
JOHN_16
Код ошибки возвращается при аварийном завершении работы программы - это UNIX way.
Так, это Вы про Питон или вообще?
Интересно, на каком уровне вложенности вызовов функций оптимальным будет завершить программу с возвращением кода ошибки sys.exit()?
А функции тогда просто возвращают результат своей работы (если есть, что возвращать)?
не вижу сути проблемы
если есть ошибка, если нужно перехвати, если нужно рейзни свою
если есть ошибка, если нужно перехвати, если нужно рейзни свою
sander
не вижу сути проблемыесли есть ошибка, если нужно перехвати, если нужно рейзни свою
Скажем так, я привык к Си, там несколько иной подход.
А тут появилась альтернатива… и надо выбрать: что, когда и как использовать
Пока применяю смешанный подход, иногда ошибки из функций возвращаются с помощью return, иногда с помощью raise. Но return, судя по всему, для этого использовать не особо питонически…
Ошибку следует возвращать явно, когда вызывающий код точно знает что с ней делать (имеет всю необходимую информацию, чтобы это определить).
Исключение кидается, когда вызывающий код может не знать что с этой ошибкой делать (не имеет информации для принятия решения). В этом случае кинуть исключение проще, чем делать проброс ошибки через 100500 функций.
Исключение кидается, когда вызывающий код может не знать что с этой ошибкой делать (не имеет информации для принятия решения). В этом случае кинуть исключение проще, чем делать проброс ошибки через 100500 функций.
Tiendil
как раз таки наоборот. Описывается собственный класс ошибки, в любом месте генерируется исключение на основе этого класса. Далее если блок try принимающий либо знает что с ним делать либо отправляет дальше. Случай если не знает что делать вообще больше похож на ситуацию когда код аварийно завершает свое выполнение. Т.е. выглядит это условно так:
как раз таки наоборот. Описывается собственный класс ошибки, в любом месте генерируется исключение на основе этого класса. Далее если блок try принимающий либо знает что с ним делать либо отправляет дальше. Случай если не знает что делать вообще больше похож на ситуацию когда код аварийно завершает свое выполнение. Т.е. выглядит это условно так:
try: # код здесь except My_little_warning: # на случай ожидаемой ошибки можно предпринять небольшие действия, # не отражающиеся на работе кода в целом. Или попробовать другие # аргументы для кода выполняющего ся в цикле и перебирающие варианты # в поисках рабочего и т.д. и .т.п except My_exception: # произошла ошибка, пишем в лог, отменяем транзакцию и тп except Exception: # тот самый случай кода мы не знаем что за ошибка, но не надо # аварийно завершать код except BaseException: # видел вот такой вот прием - т.к. этот класс находится выше всех # остальных в иерархии, то его явная генерация как раз на случай # "запланированного аварийного завершения"