Что случится с объектом exception после того как исключение было обработано

Собеседование по Java — исключения (exceptions) (вопросы и ответы)

Список вопросов и ответов по теме «Исключения в Java».

К списку вопросов по всем темам

Вопросы

1. Дайте определение понятию “исключение”
2. Какова иерархия исключений.
3. Можно/нужно ли обрабатывать ошибки jvm?
4. Какие существуют способы обработки исключений?
5. О чем говорит ключевое слово throws?
6. В чем особенность блока finally? Всегда ли он исполняется?
7. Может ли не быть ни одного блока catch при отлавливании исключений?
8. Могли бы вы придумать ситуацию, когда блок finally не будет выполнен?
9. Может ли один блок catch отлавливать несколько исключений (с одной и разных веток наследований)?
10. Что вы знаете об обрабатываемых и не обрабатываемых (checked/unchecked) исключениях?
11. В чем особенность RuntimeException?
12. Как написать собственное (“пользовательское”) исключение? Какими мотивами вы будете руководствоваться при выборе типа исключения: checked/unchecked?
13. Какой оператор позволяет принудительно выбросить исключение?
14. Есть ли дополнительные условия к методу, который потенциально может выбросить исключение?
15. Может ли метод main выбросить исключение во вне и если да, то где будет происходить обработка данного исключения?
16. Если оператор return содержится и в блоке catch и в finally, какой из них “главнее”?
17. Что вы знаете о OutOfMemoryError?
18. Что вы знаете о SQLException? К какому типу checked или unchecked оно относится, почему?
19. Что такое Error? В каком случае используется Error. Приведите пример Error’а.
20. Какая конструкция используется в Java для обработки исключений?
21. Предположим, есть блок try-finally. В блоке try возникло исключение и выполнение переместилось в блок finally. В блоке finally тоже возникло исключение. Какое из двух исключений “выпадет” из блока try-finally? Что случится со вторым исключением?
22. Предположим, есть метод, который может выбросить IOException и FileNotFoundException в какой последовательности должны идти блоки catch? Сколько блоков catch будет выполнено?

Ответы

1. Дайте определение понятию “исключение”

Исключение — это проблема(ошибка) возникающая во время выполнения программы. Исключения могут возникать во многих случаях, например:

Все исключения в Java являются объектами. Поэтому они могут порождаться не только автоматически при возникновении исключительной ситуации, но и создаваться самим разработчиком.

2. Какова иерархия исключений.

Исключения делятся на несколько классов, но все они имеют общего предка — класс Throwable. Его потомками являются подклассы Exception и Error.

Исключения (Exceptions) являются результатом проблем в программе, которые в принципе решаемы и предсказуемы. Например, произошло деление на ноль в целых числах.

Ошибки (Errors) представляют собой более серьёзные проблемы, которые, согласно спецификации Java, не следует пытаться обрабатывать в собственной программе, поскольку они связаны с проблемами уровня JVM. Например, исключения такого рода возникают, если закончилась память, доступная виртуальной машине. Программа дополнительную память всё равно не сможет обеспечить для JVM.

В Java все исключения делятся на два типа: контролируемые исключения (checked) и неконтролируемые исключения (unchecked), к которым относятся ошибки (Errors) и исключения времени выполнения (RuntimeExceptions, потомок класса Exception).

Контролируемые исключения представляют собой ошибки, которые можно и нужно обрабатывать в программе, к этому типу относятся все потомки класса Exception (но не RuntimeException).

3. Можно/нужно ли обрабатывать ошибки jvm?

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

4. Какие существуют способы обработки исключений?

Общий вид конструкции для «поимки» исключительной ситуации выглядит следующим образом:

Источник

Правильное использование исключений в Java

Доброго времени суток, уважаемый Хабр.
Я хотел бы рассказать, как правильно нужно использовать исключения в Java. Частично этот материал рассматривается на просторах интернета, а также рассматривается немного в книге J.Bloch Effective Java. Речь пойдет о использовании проверенных и непроверенных (checked/unchecked) исключениях. Статья будет полезна новичкам, т.к. вначале не всегда ясно, как правильно нужно пользоваться исключениями.

Иерархия исключений в Java представлена следующим образом: родительский класс для всех Throwable. От него унаследовано 2 класса: Exception и Error. От класса Exception унаследован еще RuntimeException.
Error – критические ошибки, который могут возникнуть в системе (например, StackOverflowError ). Как правило обрабатывает их система. Если они возникают, то приложение закрывается, так как при данной ситуации работа не может быть продолжена.

Exception – это проверенные исключения. Это значит, что если метод бросает исключение, которое унаследовано от Exception (напр. IOException), то этот метод должен быть обязательно заключен в блок try-catch. Сам метод, который бросает исключение, должен в сигнатуре содержать конструкцию throws. Проверенные (checked) исключения означают, что исключение можно было предвидеть и, соответственно, оно должно быть обработано, работа приложения должна быть продолжена. Пример такого исключения — это попытка создать новый файл, который уже существует (IOException). В данному случае, работа приложения должна быть продолжена и пользователь должен получить уведомление, по какой причине файл не может быть создан.
Например:

В данном примере можно увидеть, что метод createTempFile может выбрасывать IOException, когда файл не может быть создан. И это исключение должно быть обработано соответственно. Если попытаться вызвать этот метод вне блока try-catch, то компилятор выдаст ошибку и будет предложено 2 варианта исправления: окружить метод блоком try-catch или метод, внутри которого вызывается File.createTempFile, должен выбрасывать исключение IOException (чтобы передать его на верхний уровень для обработки).

RuntimeException – это непроверенные исключения. Они возникают во время выполнения приложения. К таким исключениям относится, например, NullPointerException. Они не требуют обязательного заключения в блок try-catch. Когда RuntimeException возникает, это свидетельствует о ошибке, допущенной программистом (неинициализированный объект, выход за пределы массива и т.д.). Поэтому данное исключение не нужно обрабатывать, а нужно исправлять ошибку в коде, чтобы исключение вновь не возникало.
Ниже приведен пример, как правильно работать с RuntimeException:

В данном примере метод принимает объект класса Rectangle. В описании метода содержится строка @throws, которая описывает исключение, которое может быть выброшено и при каких условиях. Однако, сигнатура метода не содержит конструкции throws. Это значит, что при вызове метода его не нужно оборачивать блоком try-catch. А программист должен не допустить передачи в метод неинициализированного объекта.

Надеюсь, такие небольшие разъяснения могут немного разобраться, когда же нужно обрабатывать исключения, а когда нужно просто исправлять ошибки в коде.

Источник

С++ exception handling под капотом или как же работают исключения в C++

От переводчика

На хабре есть несколько статей, подробных и не очень (при этом все равно хороших), посвященных тому, как работают exceptions в C++. Однако нет ни одной по-настоящему глубокой, поэтому я решил восполнить этот пробел, благо есть подходящий материал. Кому интересно как работают исключения в C++ на примере gcc — запаситесь pocket-ом или evernote, свободным временем и добро пожаловать под кат.

2 часть
3 часть

P.S. Пару слов о переводе:

C++ исключения под капотом

Для начала нужно спросить себя: как это все работает? Это первая статья из длинной серии, которую я пишу о том, как реализованы исключения под капотом в C++ (под платформу gcc под x86, но должно быть применимо для других платформ так же). В этих статьях процес выброса и отлова ошибок будет объяснен во всех подробностях, но для нетерпеливых: короткий бриф всех статей о пробросе исключений в gcc/x86:

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

Если вы слишком любопытны, можете начинать тут. Это — полная спецификация того, что мы будем реализовывать в следующих частях. Я же попытаюсь сделать эту статью поучительной и более простой, чтобы в следующий раз вам было проще начинать с вашим собственным ABI (application binary interface, Двоичный интерфейс приложений — прим. переводчика).

Примечания (отказ от ответственности):
Я ни в коей мере не сведую в том, какая вуду-магия происходит, когда пробрасывается исключение. В этой статье я попытаюсь разоблачить тайное и узнать, как же оно устроено. Какие-то мелочи и тонкости будут не соответствовать действительности. Пожалуйста, дайте мне знать, если где-то что-то неправильно.

Прим. переводчика: это актуально и для перевода.

C++ exceptions под капотом: маленький ABI

Если мы попытаемся понять, почему исключения такие сложные и как они работают, мы можем либо утонуть в тоннах мануалов и документаций, либо попытаться отловить исключения самостоятельно. В действительности, я был удивлен отстутствием качественной информации по теме (прим. переводчика — я, к слову, тоже): все, что можно найти либо чересчур детально, либо слишком уж простое. Конечно же, есть спецификации (наиболее документировано: ABI for C++, но так же CFI, DWARF и libstdc), но обособленного чтение документации недостаточно, если вы действительно хотите понять, что происходит внутри.

Давайте начнем с очевидного: с переизобретения колеса! Мы знаем, что в чистом C нет исключений, так что попытаемся слинковать C++ программу линкером чистого C и посмотрим, что произойдет! Я начал с чего-то простого типа этого:

И очень простой main:

Что случится, если мы попытаемся скомпилировать и слинковать этот франкинкод?

Заметка: вы можете загрузить весь исходный код для этого проекта с моего гит-репозитория.

Пока что все хорошо. Оба, g++ и gcc, счастливы в своем маленьком мире. Хаос начнется сразу, как только мы попробуем их слинковать вместе:

C++ exceptions под капотом: угождаем линкеру, подпихнув ему ABI

Тем не менее, мы хотим понять как именно работают исключения, так что попробуем реализовать свой собственный mini-ABI, обеспечивающий механизм пробрасывания ошибок. Чтобы сделать это, нам понадобится лишь RTFM, однако полный интерфейс может быть найден тут, для LLVM. Вспомним-ка, каких конкретно функций недостает:

__cxa_allocate_exception

Имя самодостаточно, я полагаю. __cxa_allocate_exception принимает size_t и выделяет достаточное количество памяти для хранения исключения во время его пробрасывания. Это сложнее, чем кажется: когда ошибка обрабатывается, происходит некая магия со стеком, аллоцирование (прим. переводчика — да простите за это слово, но иногда я буду его использовать) в стеке — плохая идея. Выделение памяти в куче (heap), в общем, тоже плохая идея, потому что где будем выделять память при исключении, сигнализирующем о том, что память закончилась? Статичное (static) размещение в памяти так же плохая идея, покуда нам нужно сделать это потокобезопасным (иначе два конкурирующих потока, выбросившие исключения, приведут к катастрофе). Учитывая эти проблемы, наиболее выгодным выглядит выделение памяти в локальном хранилище потока (куче), однако при необходимости обращаться к аварийному хранилищу (предположительно, статичному), если память закончилась (out of memory). Мы, конечно же, не будем волноваться по поводу страшных деталей, так что можем просто использовать статичный буфер, если понадобится.

__cxa_throw

vtable для __cxxabiv1::__class_type_info

Странно… __class_type_info явно какая-то RTTI (run-time type information, run-time type identification, Динамическая идентификация типа данных), но какая именно? Пока нам не просто ответить на это, да и это не адски важно для нашего мини-ABI; оставим это части «приложение», которую мы приведем после завершения анализа процесса пробрасывания исключения, сейчас же давайте просто скажем, что это — точка входа определения ABI в рантайме, отвечающая на вопрос: «эти два типа одинаковы или нет». Это функция, которая вызывается, чтобы определить: может ли данный catch-блок обрабатывать эту ошибку или нет. Сейчас мы сфокусируемся на основном: нам необходимо дать её как адрес для линкера (т.е. определить её не достаточно, нужно еще её инициировать) и она должна иметь vtable (да да, она должна иметь виртуальный метод).

Много работы происходит в этих функциях, но давайте попробуем реализовать простейший метатель исключений: тот, который будет делать выход из программы (call exit), когда исключение выброшено. Наше приложение почти завершено, но пропущены некоторые ABI-функции, так что давайте создадим mycppabi.cpp. Читая нашу ABI-спецификацию, мы можем описать наши сигнатуры для __cxa_allocate_exception и __cxa_throw:

Напомню: вы можете найти исходники в моем github репозитории.

Даже больше магии: когда throw транслируется в эти два вызова, компилятор даже не знает, как исключение будет обрабатываться. Как только libstdc++ определяет __cxa_throw и её друзей, libstdc++ динамически линкуется в рантайме, метод обработки исключений может быть выбран при первом запуске приложения.

Мы уже видим прогресс, но нам еще стоит пройти огромный путь познания. Сейчас наш ABI может только выбрасывать исключения. Можем ли мы расширить его, чтобы он отлавливал ошибки? Что ж, посмотрим, как это сделать, в следующей главе!

C++ exceptions под капотом: отлов того, что бросаем

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

Как и ранее, мы имеем функцию seppuku, соединяющую C и C++ миры, только в этот раз мы добавили несколько вызовов функций, чтобы сделать наш стэк более интересным, также мы добавили ветви try/catch блоков, так что теперь мы можем анализировать как libstdc++ обрабатывает их.

И вновь получаем ошибки линковщика об отсутствующих ABI-функциях:

Мы опять видим кучу всего интересного. Вызов __cxa_begin_catch и __cxa_end_catch мы ожидали, хоть пока и не знаем, что они такое, но можем предположить, что они эквивалентны throw/__cxa_allocate/throw. __gxx_personality_v0 — что-то новое, и оно и будет основной темой следующих частей.

Что делает персональная функция? (при. переводчика — не придумал лучшего названия, подскажите в комментариях, если есть идеи). Мы уже что-то говорили о ней во введении, однако в следующий раз мы посмотрим на нее гораздо детальнее, как и на наших двух новых друзей: __cxa_begin_catch и __cxa_end_catch.

C++ exceptions под капотом: магия вокруг __cxa_begin_catch и __cxa_end_catch

После изучения того, как исключения выбрасываются, мы оказались на пути изучения, как они отлавливаются. В предыдущей главе мы добавили в наш пример приложения try-catch-блок, чтобы увидеть что делает компилятор, а так же получили ошибки линкера прямо как в прошлый раз, когда мы смотрели, что произойдет если добавить throw-блок. Вот что пишет линкер:

Напомню, что код вы можете получить на моем гит-репозитории.

В теории (в нашей теории, разумеется), catch-блок транслируется в пару __cxa_begin_catch/end_catch из libstdc++, но и во что-то новое, называемое персональной функцией, о который мы пока еще ничего не знаем.

Все идет замечательно: мы получили такое же определение для raise(), лишь выброс исключения:

Определение для try_but_dont_catch() обрезано компилятором. Это что-то новое: ссылка на __gxx_personality_v0 и что-то другое, называемое LSDA. Это выглядит незначительным определением, однако в действительности это очень важно:

Лишь обычный возврат функции… с некоторым мусором CFI в нем.

Это все для обработки ошибок, тем не менее, мы до сих пор не знаем, как работают __cxa_begin/end_catch; у нас есть идеи как эта пара формирует то, что называет landing pad — место в функции, где располагаются обраотчики исключений. Что мы пока не знаем — как landing pads ищутся. Unwind должен как-то пройти все вызовы в стеке, проверить: имеет ли какой-либо вызов (фрейм стека для точности) валидный блок с landing pad, который может обрабатывать это исключение, и продолжить выполнение в нем.

Это немаловажное достижение, и как это работает мы выясним в следующей главе.

C++ exceptions под капотом: gcc_except_table и персональная функция

Ранее мы выяснили, что throw транслируется в пару __cxa_allocate_exception/throw, а catch-блок транслируется в __cxa_begin/end_catch, а также во что-то, именуемое CFI (call frame information) для поиска landing pads — точки входа обработчиков ошибок.

Что мы не знаем до сих пор, это как _Unwind узнает, где этот landing pads. Когда исключение пробрасывается сквозь связку функций в стэке, все CFI позволяют программе разворачивания стэка узнать, что за функция сейчас исполняется, а так же это необходимо, чтобы узнать, какой из landing pads функции позволяет нам обрабатывать данное исключение (и, к слову, мы игнорируем функции с множественными try/catch блоками!).

Чтобы выяснить, где же этот landing pads находится, используется что-то, зовущее себя gcc_except_table. Таблица эта может быть найдена (с мусором CFI) после конца функции:

Эта секция .gcc_except_table — где хранится вся информация для обнаружения landing pads, мы поговорим об этом позже, когда будем анализировать персональную функцию. Пока что мы лишь скажем, что LSDA означает — зона с специфичными для языка данными, которые персональная функция проверяет на наличие landing pads для функции (она также используется для запуска деструкторов в процессе разворачивания стэка).

Подытожим: для каждой функции, где есть по крайней мере один catch-блок, компилятор транслирует его в пару вызовов cxa_begin_catch/cxa_end_catch и, затем, персональная функция, вызываемая __cxa_throw, читает gcc_except_table для каждого метода в стэке для поиска чего-то, называемого LSDA. Персональная функция затем проверяет, есть ли в LSDA блок, обрабатывающий данное исключение, а так же есть ли какой-то код очистки (который запускает деструкторы когда нужно).

Еще мы можем сделать интересный вывод: если мы используем nothrow (или пустой оператор throw), компилятор может опустить gcc_except_table для метода. Этот способ реализации исключений в gcc, не сильно влияющий на производительность, в действительности сильно влияет на размер кода. Что касается catch-блоков? Если исключение пробрасывается, когда объявлен спецификатор nothrow, LSDA не генерируется и персональная функция не знает, что ей делать. Когда персональная функция не знает, что ей делать, она вызывает обработчик ошибок по-умолчанию, что, в большинстве случаев, означает, что выброс ошибки из nothrow метода закончится std::terminate.

Теперь, когда у нас есть идеи, что делает персональная функция, сможем ли мы реализовать её? Что ж, посмотрим!

Источник

Обработка исключений в Python (try except)

П рограмма, написанная на языке Python, останавливается сразу как обнаружит ошибку. Ошибки могут быть (как минимум) двух типов:

Как устроен механизм исключений

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

💁‍♂️ Пример : напишем скрипт, в котором функция ожидает число, а мы передаём сроку (это вызовет исключение «TypeError»):

Далее ошибка передается по цепочке в обратном направлении: » b » → » a » → » test.py «. Так как в данном примере мы не позаботились обработать эту ошибку, вся информация по ошибке отобразится в консоли в виде Traceback.

Traceback (трассировка) — это отчёт, содержащий вызовы функций, выполненные в определенный момент. Трассировка помогает узнать, что пошло не так и в каком месте это произошло.

Traceback лучше читать снизу вверх ↑

В нашем примере Traceback содержится следующую информацию (читаем снизу вверх):

Как обрабатывать исключения в Python (try except)

Например, вот как можно обработать ошибку деления на ноль:

try: a = 7 / 0 except: print(‘Ошибка! Деление на 0’)

Здесь в блоке try находится код a = 7 / 0 — при попытке его выполнить возникнет исключение и выполнится код в блоке except (то есть будет выведено сообщение «Ошибка! Деление на 0»). После этого программа продолжит свое выполнение.

💭 PEP 8 рекомендует, по возможности, указывать конкретный тип исключения после ключевого слова except (чтобы перехватывать и обрабатывать конкретные исключения):

try: a = 7 / 0 except ZeroDivisionError: print(‘Ошибка! Деление на 0’)

Однако если вы хотите перехватывать все исключения, которые сигнализируют об ошибках программы, используйте тип исключения Exception :

try: a = 7 / 0 except Exception: print(‘Любая ошибка!’)

As — сохраняет ошибку в переменную

Перехваченная ошибка представляет собой объект класса, унаследованного от «BaseException». С помощью ключевого слова as можно записать этот объект в переменную, чтобы обратиться к нему внутри блока except :

try: file = open(‘ok123.txt’, ‘r’) except FileNotFoundError as e: print(e) > [Errno 2] No such file or directory: ‘ok123.txt’

В примере выше мы обращаемся к объекту класса «FileNotFoundError» (при выводе на экран через print отобразится строка с полным описанием ошибки).

У каждого объекта есть поля, к которым можно обращаться (например если нужно логировать ошибку в собственном формате):

import datetime now = datetime.datetime.now().strftime(«%d-%m-%Y %H:%M:%S») try: file = open(‘ok123.txt’, ‘r’) except FileNotFoundError as e: print(f» [FileNotFoundError]: , filename: «) > 20-11-2021 18:42:01 [FileNotFoundError]: No such file or directory, filename: ok123.txt

Finally — выполняется всегда

Обычно try/except используется для перехвата исключений и восстановления нормальной работы приложения, а try/finally для того, чтобы гарантировать выполнение определенных действий (например, для закрытия внешних ресурсов, таких как ранее открытые файлы).

В следующем примере откроем файл и обратимся к несуществующей строке:

file = open(‘ok.txt’, ‘r’) try: lines = file.readlines() print(lines[5]) finally: file.close() if file.closed: print(«файл закрыт!») > файл закрыт! > Traceback (most recent call last): > File «test.py», line 5, in > print(lines[5]) > IndexError: list index out of range

p.s. данный пример создан для демонстрации, в реальном проекте для работы с файлами лучше использовать менеджер контекста with.

Else — выполняется когда исключение не было вызвано

Допустим нужно вывести результат деления двух чисел и обработать исключения в случае попытки деления на ноль:

b = int(input(‘b = ‘)) c = int(input(‘c = ‘)) try: a = b / c except ZeroDivisionError: print(‘Ошибка! Деление на 0’) else: print(f»a = «) > b = 10 > c = 1 > a = 10.0

В этом случае, если пользователь присвоит переменной » с » ноль, то появится исключение и будет выведено сообщение «‘Ошибка! Деление на 0′», а код внутри блока else выполняться не будет. Если ошибки не будет, то на экране появятся результаты деления.

Несколько блоков except

В программе может возникнуть несколько исключений, например:

В Python, чтобы по-разному обрабатывать разные типы ошибок, создают несколько блоков except :

try: b = float(input(‘b = ‘)) c = float(input(‘c = ‘)) a = b / c except ZeroDivisionError: print(‘Ошибка! Деление на 0’) except ValueError: print(‘Число введено неверно’) else: print(f»a = «) > b = 10 > c = 0 > Ошибка! Деление на 0 > b = 10 > c = питон > Число введено неверно

Теперь для разных типов ошибок есть свой обработчик.

Несколько типов исключений в одном блоке except

try: b = float(input(‘b = ‘)) c = float(input(‘c = ‘)) a = b / c except (ZeroDivisionError, ValueError) as er: print(er) else: print(‘a = ‘, a)

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

Raise — самостоятельный вызов исключений

min = 100 if min > 10: raise Exception(‘min must be less than 10’) > Traceback (most recent call last): > File «test.py», line 3, in > raise Exception(‘min value must be less than 10’) > Exception: min must be less than 10

Перехватываются такие сообщения точно так же, как и остальные:

min = 100 try: if min > 10: raise Exception(‘min must be less than 10’) except Exception: print(‘Моя ошибка’) > Моя ошибка

Кроме того, ошибку можно обработать в блоке except и пробросить дальше (вверх по стеку) с помощью raise :

min = 100 try: if min > 10: raise Exception(‘min must be less than 10’) except Exception: print(‘Моя ошибка’) raise > Моя ошибка > Traceback (most recent call last): > File «test.py», line 5, in > raise Exception(‘min must be less than 10’) > Exception: min must be less than 10

Как пропустить ошибку

Иногда ошибку обрабатывать не нужно. В этом случае ее можно пропустить с помощью pass :

try: a = 7 / 0 except ZeroDivisionError: pass

Исключения в lambda функциях

Обрабатывать исключения внутри lambda функций нельзя (так как lambda записывается в виде одного выражения). В этом случае нужно использовать именованную функцию.

20 типов встроенных исключений в Python

Иерархия классов для встроенных исключений в Python выглядит так:

Все исключения в Python наследуются от базового BaseException :

От Exception наследуются:

1 StopIteration — вызывается функцией next в том случае если в итераторе закончились элементы;

2 ArithmeticError — ошибки, возникающие при вычислении, бывают следующие типы:

3 AssertionError — выражение, используемое в функции assert неверно;

4 AttributeError — у объекта отсутствует нужный атрибут;

5 BufferError — операция, для выполнения которой требуется буфер, не выполнена;

6 EOFError — ошибка чтения из файла;

7 ImportError — ошибка импортирования модуля;

8 LookupError — неверный индекс, делится на два типа:

9 MemoryError — память переполнена;

10 NameError — отсутствует переменная с данным именем;

11 OSError — исключения, генерируемые операционной системой:

12 ReferenceError — попытка доступа к объекту с помощью слабой ссылки, когда объект не существует;

13 RuntimeError — генерируется в случае, когда исключение не может быть классифицировано или не подпадает под любую другую категорию;

14 NotImplementedError — абстрактные методы класса нуждаются в переопределении;

15 SyntaxError — ошибка синтаксиса;

16 SystemError — сигнализирует о внутренне ошибке;

17 TypeError — операция не может быть выполнена с переменной этого типа;

18 ValueError — возникает когда в функцию передается объект правильного типа, но имеющий некорректное значение;

20 Warning — предупреждение, некритическая ошибка.

💭 Посмотреть всю цепочку наследования конкретного типа исключения можно с помощью модуля inspect :

Как создать свой тип Exception

В Python можно создавать свои исключения. При этом есть одно обязательное условие: они должны быть потомками класса Exception :

class MyError(Exception): def __init__(self, text): self.txt = text try: raise MyError(‘Моя ошибка’) except MyError as er: print(er) > Моя ошибка

С помощью try/except контролируются и обрабатываются ошибки в приложении. Это особенно актуально для критически важных частей программы, где любые «падения» недопустимы (или могут привести к негативным последствиям). Например, если программа работает как «демон», падение приведет к полной остановке её работы. Или, например, при временном сбое соединения с базой данных, программа также прервёт своё выполнения (хотя можно было отловить ошибку и попробовать соединиться в БД заново).

Вместе с try/except можно использовать дополнительные блоки. Если использовать все блоки описанные в статье, то код будет выглядеть так:

try: # попробуем что-то сделать except (ZeroDivisionError, ValueError) as e: # обрабатываем исключения типа ZeroDivisionError или ValueError except Exception as e: # исключение не ZeroDivisionError и не ValueError # поэтому обрабатываем исключение общего типа (унаследованное от Exception) # сюда не сходят исключения типа GeneratorExit, KeyboardInterrupt, SystemExit else: # этот блок выполняется, если нет исключений # если в этом блоке сделать return, он не будет вызван, пока не выполнился блок finally finally: # этот блок выполняется всегда, даже если нет исключений else будет проигнорирован # если в этом блоке сделать return, то return в блоке

Источник