Исключения возникают тогда, когда в программе возникает некоторая исключительная ситуация. Например, к чему приведёт попытка чтения несуществующего файла? Или если файл был случайно удалён, пока программа работала? Такие ситуации обрабатываются при помощи исключений.
Это касается и программ, содержащих недействительные команды. В этом случае Python поднимает руки и сообщает, что обнаружил ошибку.
Ошибки¶
Рассмотрим простой вызов функции print . Что, если мы ошибочно напишем print как Print ? Обратите внимание на заглавную букву. В этом случае Python поднимает синтаксическую ошибку.
Обратите внимание, что была поднята ошибка NameError , а также указано место, где была обнаружена ошибка. Так в данном случае действует обработчик ошибок.
Исключения¶
Попытаемся считать что-либо от пользователя. Нажмите Сtrl-D (или Ctrl+Z в Windows) и посмотрите, что произойдёт.
Python поднимает ошибку с именем EOFError , что означает, что он обнаружил символ конца файла (который вводится при помощи Ctrl-D ) там, где не ожидал.
Обработка исключений¶
Обрабатывать исключения можно при помощи оператора try..except [1]. При этом все обычные команды помещаются внутрь try-блока, а все обработчики исключений – в except-блок.
Пример: (сохраните как try_except.py )
Вывод:
Как это работает:
Помните, что для каждого выражения try должно быть хотя бы одно соответствующее выражение except . Иначе какой смысл был бы в блоке try ?
Если ошибка или исключение не обработано, будет вызван обработчик Python по умолчанию, который останавливает выполнение программы и выводит на экран сообщение об ошибке. Выше мы уже видели это в действии.
Можно также добавить пункт else к соответствующему блоку try..except . Этот пункт будет выполнен тогда, когда исключений не возникает.
В следующем примере мы увидим, как можно получить объект исключения для дальнейшей работы с ним.
Вызов исключения¶
Исключение можно поднять при помощи оператора raise [2], передав ему имя ошибки/исключения, а также объект исключения, который нужно выбросить.
Вызываемая ошибка или исключение должна быть классом, который прямо или непрямо является производным от класса Exception .
Пример: (сохраните как raising.py )
Вывод:
Как это работает:
Здесь мы создаём наш собственный тип исключения. Этот новый тип исключения называется ShortInputException . Он содержит два поля: length , хранящее длину введённого текста, и atleast , указывающее, какую минимальную длину текста ожидала программа.
В пункте except мы указываем класс ошибки ShortInputException , который будет сохранён как[3] переменная ex , содержащая соответствующий объект ошибки/исключения. Это аналогично параметрам и аргументам при вызове функции. Внутри этого пункта except мы используем поля length и atleast объекта исключения для вывода необходимых сообщений пользователю.
Try .. Finally¶
Представим, что в программе происходит чтение файла и необходимо убедиться, что объект файла был корректно закрыт и что не возникло никакого исключения. Этого можно достичь с применением блока finally .
Сохраните как finally.py :
Вывод:
Как это работает:
Здесь мы производим обычные операции чтения из файла, но в данном случае добавляем двухсекундный сон после вывода каждой строки при помощи функции time.sleep , чтобы программа выполнялась медленно (ведь Python очень быстр от природы). Во время выполнения программы нажмите ctrl-c , чтобы прервать/отменить выполнение программы.
Пронаблюдайте, как при этом выдаётся исключение KeyboardInterrupt , и программа выходит. Однако, прежде чем программа выйдет, выполняется пункт finally , и файловый объект будет всегда закрыт.
Оператор with¶
Типичной схемой является запрос некоторого ресурса в блоке try с последующим освобождением этого ресурса в блоке finally . Для того, чтобы сделать это более “чисто”, существует оператор with [4]:
Сохраните как using_with.py :
Как это работает:
Вывод должен быть таким же, как и в предыдущем примере. Разница лишь в том, что здесь мы используем функцию open с оператором with – этим мы оставляем автоматическое закрытие файла под ответственность with open .
За кулисами происходит следующее. Существует некий протокол, используемый оператором with . Он считывает объект, возвращаемый оператором open . Назовём его в данном случае “thefile”.
Перед запуском блока кода, содержащегося в нём, оператор with всегда вызывает функцию thefile.__enter__ , а также всегда вызывает thefile.__exit__ после завершения выполнения этого блока кода.
Так что код, который мы бы написали в блоке finally , будет автоматически обработан методом __exit__ . Это избавляет нас от необходимости повторно в явном виде указывать операторы try..finally .
Более обширное рассмотрение этой темы выходит за рамки настоящей книги, поэтому для более исчерпывающего объяснения см. PEP 343.
Резюме¶
Мы обсудили использование операторов try..except и try..finally . Мы также увидели, как создавать наши собственные типы исключений и как их вызывать.
Далее мы ознакомимся со стандартной библиотекой Python.
EOF — это не символ
Недавно я читал книгу «Компьютерные системы: архитектура и программирование. Взгляд программиста». Там, в главе про систему ввода-вывода Unix, авторы упомянули о том, что в конце файла нет особого символа EOF .
Если вы читали о системе ввода-вывода Unix/Linux, или экспериментировали с ней, если писали программы на C, которые читают данные из файлов, то это заявление вам, вероятно, покажется совершенно очевидным. Но давайте поближе присмотримся к следующим двум утверждениям, относящимся к тому, что я нашёл в книге:
- EOF — это не символ.
- В конце файлов нет некоего особого символа.
Что же такое EOF ?
EOF — это не символ
Почему кто-то говорит или думает, что EOF — это символ? Полагаю, это может быть так из-за того, что в некоторых программах, написанных на C, можно найти код, в котором используется явная проверка на EOF с использованием функций getchar() и getc() .
Это может выглядеть так:
Если заглянуть в справку по getchar() или getc() , можно узнать, что обе функции считывают следующий символ из потока ввода. Вероятно — именно это является причиной возникновения заблуждения о природе EOF . Но это — лишь мои предположения. Вернёмся к мысли о том, что EOF — это не символ.
А что такое, вообще, символ? Символ — это самый маленький компонент текста. «A», «a», «B», «b» — всё это — разные символы. У символа есть числовой код, который в стандарте Unicode называют кодовой точкой. Например — латинская буква «A» имеет, в десятичном представлении, код 65. Это можно быстро проверить, воспользовавшись командной строкой интерпретатора Python:
Или можно взглянуть на таблицу ASCII в Unix/Linux:
Выясним, какой код соответствует EOF , написав небольшую программу на C. В ANSI C константа EOF определена в stdio.h , она является частью стандартной библиотеки. Обычно в эту константу записано -1 . Можете сохранить следующий код в файле printeof.c , скомпилировать его и запустить:
Скомпилируем и запустим программу:
У меня эта программа, проверенная на Mac OS и на Ubuntu, сообщает о том, что EOF равняется -1 . Есть ли какой-нибудь символ с таким кодом? Тут, опять же, можно проверить коды символов в таблице ASCII, можно взглянуть на таблицу Unicode и узнать о том, в каком диапазоне могут находиться коды символов. Мы же поступим иначе: запустим интерпретатор Python и воспользуемся стандартной функцией chr() для того, чтобы она дала бы нам символ, соответствующий коду -1 :
Как и ожидалось, символа с кодом -1 не существует. Значит, в итоге, EOF , и правда, символом не является. Переходим теперь ко второму рассматриваемому утверждению.
В конце файлов нет некоего особого символа
Может, EOF — это особенный символ, который можно обнаружить в конце файла? Полагаю, сейчас вы уже знаете ответ. Но давайте тщательно проверим наше предположение.
Возьмём простой текстовый файл, helloworld.txt, и выведем его содержимое в шестнадцатеричном представлении. Для этого можно воспользоваться командой xxd :
Как видите, последний символ файла имеет код 0a . Из таблицы ASCII можно узнать о том, что этот код соответствует символу nl , то есть — символу новой строки. Это можно выяснить и воспользовавшись Python:
Так. EOF — это не символ, а в конце файлов нет некоего особого символа. Что же такое EOF ?
Что такое EOF?
EOF (end-of-file) — это состояние, которое может быть обнаружено приложением в ситуации, когда операция чтения файла доходит до его конца.
Взглянем на то, как можно обнаруживать состояние EOF в разных языках программирования при чтении текстового файла с использованием высокоуровневых средств ввода-вывода, предоставляемых этими языками. Для этого напишем очень простую версию cat , которая будет называться mcat . Она побайтно (посимвольно) читает ASCII-текст и в явном виде выполняет проверку на EOF . Программу напишем на следующих языках:
- ANSI C
- Python 3
- Go
- JavaScript (Node.js)
Вот репозиторий с кодом примеров. Приступим к их разбору.
ANSI C
Начнём с почтенного C. Представленная здесь программа является модифицированной версией cat из книги «Язык программирования C».
Вот некоторые пояснения, касающиеся вышеприведённого кода:
- Программа открывает файл, переданный ей в виде аргумента командной строки.
- В цикле while осуществляется копирование данных из файла в стандартный поток вывода. Данные копируются побайтово, происходит это до тех пор, пока не будет достигнут конец файла.
- Когда программа доходит до EOF , она закрывает файл и завершает работу.
Python 3
В Python нет механизма явной проверки на EOF , похожего на тот, который имеется в ANSI C. Но если посимвольно читать файл, то можно выявить состояние EOF в том случае, если в переменной, хранящей очередной прочитанный символ, будет пусто:
Запустим программу и взглянём на возвращаемые ей результаты:
Вот более короткая версия этого же примера, написанная на Python 3.8+. Здесь используется оператор := (его называют «оператор walrus» или «моржовый оператор»):
Запустим этот код:
В Go можно явным образом проверить ошибку, возвращённую Read(), на предмет того, не указывает ли она на то, что мы добрались до конца файла:
JavaScript (Node.js)
В среде Node.js нет механизма для явной проверки на EOF . Но, когда при достижении конца файла делается попытка ещё что-то прочитать, вызывается событие потока end.
Низкоуровневые системные механизмы
Как высокоуровневые механизмы ввода-вывода, использованные в вышеприведённых примерах, определяют достижение конца файла? В Linux эти механизмы прямо или косвенно используют системный вызов read(), предоставляемый ядром. Функция (или макрос) getc() из C, например, использует системный вызов read() и возвращает EOF в том случае, если read() указывает на возникновение состояния достижения конца файла. В этом случае read() возвращает 0 . Если изобразить всё это в виде схемы, то получится следующее:
Получается, что функция getc() основана на read() .
Напишем версию cat , названную syscat , используя только системные вызовы Unix. Сделаем мы это не только из интереса, но и из-за того, что это вполне может принести нам какую-то пользу.
Вот эта программа, написанная на C:
В этом коде используется тот факт, что функция read() , указывая на достижение конца файла, возвращает 0 .
Вот та же программа, написанная на Python 3:
Вот — то же самое, написанное на Python 3.8+:
Запустим и этот код:
Итоги
- EOF — это не символ.
- В конце файлов нет некоего особого символа.
- EOF — это состояние, о котором сообщает ядро, и которое может быть обнаружено приложением в том случае, когда операция чтения данных доходит до конца файла.
- В ANSI C EOF — это, опять же, не символ. Это — константа, определённая в stdio.h , в которую обычно записано значение -1.
- «Символ» EOF нельзя найти в таблице ASCII или в Unicode.
Уважаемые читатели! А вы знаете о каких-нибудь более или менее широко распространённых заблуждениях из мира компьютеров?
Значения исключений и ошибок в Python
Обработка ошибок увеличивает отказоустойчивость кода, защищая его от потенциальных сбоев, которые могут привести к преждевременному завершению работы.
Прежде чем переходить к обсуждению того, почему обработка исключений так важна, и рассматривать встроенные в Python исключения, важно понять, что есть тонкая грань между понятиями ошибки и исключения.
Ошибку нельзя обработать, а исключения Python обрабатываются при выполнении программы. Ошибка может быть синтаксической, но существует и много видов исключений, которые возникают при выполнении и не останавливают программу сразу же. Ошибка может указывать на критические проблемы, которые приложение и не должно перехватывать, а исключения — состояния, которые стоит попробовать перехватить. Ошибки — вид непроверяемых и невозвратимых ошибок, таких как OutOfMemoryError , которые не стоит пытаться обработать.
Обработка исключений делает код более отказоустойчивым и помогает предотвращать потенциальные проблемы, которые могут привести к преждевременной остановке выполнения. Представьте код, который готов к развертыванию, но все равно прекращает работу из-за исключения. Клиент такой не примет, поэтому стоит заранее обработать конкретные исключения, чтобы избежать неразберихи.
Ошибки могут быть разных видов:
- Синтаксические
- Недостаточно памяти
- Ошибки рекурсии
- Исключения
Разберем их по очереди.
Синтаксические ошибки (SyntaxError)
Синтаксические ошибки часто называют ошибками разбора. Они возникают, когда интерпретатор обнаруживает синтаксическую проблему в коде.
Рассмотрим на примере.
Стрелка вверху указывает на место, где интерпретатор получил ошибку при попытке исполнения. Знак перед стрелкой указывает на причину проблемы. Для устранения таких фундаментальных ошибок Python будет делать большую часть работы за программиста, выводя название файла и номер строки, где была обнаружена ошибка.
Недостаточно памяти (OutofMemoryError)
Ошибки памяти чаще всего связаны с оперативной памятью компьютера и относятся к структуре данных под названием “Куча” ( heap ). Если есть крупные объекты (или) ссылки на подобные, то с большой долей вероятности возникнет ошибка OutofMemory . Она может появиться по нескольким причинам:
- Использование 32-битной архитектуры Python (максимальный объем выделенной памяти невысокий, между 2 и 4 ГБ);
- Загрузка файла большого размера;
- Запуск модели машинного обучения/глубокого обучения и много другое;
Обработать ошибку памяти можно с помощью обработки исключений — резервного исключения. Оно используется, когда у интерпретатора заканчивается память и он должен немедленно остановить текущее исполнение. В редких случаях Python вызывает OutofMemoryError , позволяя скрипту каким-то образом перехватить самого себя, остановить ошибку памяти и восстановиться.
Но поскольку Python использует архитектуру управления памятью из языка C (функция malloc() ), не факт, что все процессы восстановятся — в некоторых случаях MemoryError приведет к остановке. Следовательно, обрабатывать такие ошибки не рекомендуется, и это не считается хорошей практикой.
Ошибка рекурсии (RecursionError)
Эта ошибка связана со стеком и происходит при вызове функций. Как и предполагает название, ошибка рекурсии возникает, когда внутри друг друга исполняется много методов (один из которых — с бесконечной рекурсией), но это ограничено размером стека.
Все локальные переменные и методы размещаются в стеке. Для каждого вызова метода создается стековый кадр (фрейм), внутрь которого помещаются данные переменной или результат вызова метода. Когда исполнение метода завершается, его элемент удаляется.
Чтобы воспроизвести эту ошибку, определим функцию recursion , которая будет рекурсивной — вызывать сама себя в бесконечном цикле. В результате появится ошибка StackOverflow или ошибка рекурсии, потому что стековый кадр будет заполняться данными метода из каждого вызова, но они не будут освобождаться.
Ошибка отступа (IndentationError)
Эта ошибка похожа по духу на синтаксическую и является ее подвидом. Тем не менее она возникает только в случае проблем с отступами.
Исключения
Даже если синтаксис в инструкции или само выражение верны, они все равно могут вызывать ошибки при исполнении. Исключения Python — это ошибки, обнаруживаемые при исполнении, но не являющиеся критическими. Скоро вы узнаете, как справляться с ними в программах Python. Объект исключения создается при вызове исключения Python. Если скрипт не обрабатывает исключение явно, программа будет остановлена принудительно.
Программы обычно не обрабатывают исключения, что приводит к подобным сообщениям об ошибке:
Ошибка типа (TypeError)
Ошибка деления на ноль (ZeroDivisionError)
Есть разные типы исключений в Python и их тип выводится в сообщении: вверху примеры TypeError и ZeroDivisionError . Обе строки в сообщениях об ошибке представляют собой имена встроенных исключений Python.
Оставшаяся часть строки с ошибкой предлагает подробности о причине ошибки на основе ее типа.
Теперь рассмотрим встроенные исключения Python.
Встроенные исключения
Прежде чем переходить к разбору встроенных исключений быстро вспомним 4 основных компонента обработки исключения, как показано на этой схеме.
- Try : он запускает блок кода, в котором ожидается ошибка.
- Except : здесь определяется тип исключения, который ожидается в блоке try (встроенный или созданный).
- Else : если исключений нет, тогда исполняется этот блок (его можно воспринимать как средство для запуска кода в том случае, если ожидается, что часть кода приведет к исключению).
- Finally : вне зависимости от того, будет ли исключение или нет, этот блок кода исполняется всегда.
В следующем разделе руководства больше узнаете об общих типах исключений и научитесь обрабатывать их с помощью инструмента обработки исключения.
Ошибка прерывания с клавиатуры (KeyboardInterrupt)
Исключение KeyboardInterrupt вызывается при попытке остановить программу с помощью сочетания Ctrl + C или Ctrl + Z в командной строке или ядре в Jupyter Notebook. Иногда это происходит неумышленно и подобная обработка поможет избежать подобных ситуаций.
В примере ниже если запустить ячейку и прервать ядро, программа вызовет исключение KeyboardInterrupt . Теперь обработаем исключение KeyboardInterrupt .
Стандартные ошибки (StandardError)
Рассмотрим некоторые базовые ошибки в программировании.
Арифметические ошибки (ArithmeticError)
- Ошибка деления на ноль (Zero Division);
- Ошибка переполнения (OverFlow);
- Ошибка плавающей точки (Floating Point);
Все перечисленные выше исключения относятся к классу Arithmetic и вызываются при ошибках в арифметических операциях.
Деление на ноль (ZeroDivisionError)
Когда делитель (второй аргумент операции деления) или знаменатель равны нулю, тогда результатом будет ошибка деления на ноль.
Переполнение (OverflowError)
Ошибка переполнение вызывается, когда результат операции выходил за пределы диапазона. Она характерна для целых чисел вне диапазона.
Ошибка утверждения (AssertionError)
Когда инструкция утверждения не верна, вызывается ошибка утверждения.
Рассмотрим пример. Предположим, есть две переменные: a и b . Их нужно сравнить. Чтобы проверить, равны ли они, необходимо использовать ключевое слово assert , что приведет к вызову исключения Assertion в том случае, если выражение будет ложным.
Ошибка атрибута (AttributeError)
При попытке сослаться на несуществующий атрибут программа вернет ошибку атрибута. В следующем примере можно увидеть, что у объекта класса Attributes нет атрибута с именем attribute .
Ошибка импорта (ModuleNotFoundError)
Ошибка импорта вызывается при попытке импортировать несуществующий (или неспособный загрузиться) модуль в стандартном пути или даже при допущенной ошибке в имени.
Ошибка поиска (LookupError)
LockupError выступает базовым классом для исключений, которые происходят, когда key или index используются для связывания или последовательность списка/словаря неверна или не существует.
Здесь есть два вида исключений:
- Ошибка индекса ( IndexError );
- Ошибка ключа ( KeyError );
Ошибка ключа
Если ключа, к которому нужно получить доступ, не оказывается в словаре, вызывается исключение KeyError .
Ошибка индекса
Если пытаться получить доступ к индексу (последовательности) списка, которого не существует в этом списке или находится вне его диапазона, будет вызвана ошибка индекса (IndexError: list index out of range python).
Ошибка памяти (MemoryError)
Как уже упоминалось, ошибка памяти вызывается, когда операции не хватает памяти для выполнения.
Ошибка имени (NameError)
Ошибка имени возникает, когда локальное или глобальное имя не находится.
В следующем примере переменная ans не определена. Результатом будет ошибка NameError .
Ошибка выполнения (Runtime Error)
Ошибка «NotImplementedError»
Ошибка выполнения служит базовым классом для ошибки NotImplemented . Абстрактные методы определенного пользователем класса вызывают это исключение, когда производные методы перезаписывают оригинальный.
Ошибка типа (TypeError)
Ошибка типа вызывается при попытке объединить два несовместимых операнда или объекта.
В примере ниже целое число пытаются добавить к строке, что приводит к ошибке типа.
Ошибка значения (ValueError)
Ошибка значения вызывается, когда встроенная операция или функция получают аргумент с корректным типом, но недопустимым значением.
В этом примере встроенная операция float получат аргумент, представляющий собой последовательность символов (значение), что является недопустимым значением для типа: число с плавающей точкой.
Пользовательские исключения в Python
В Python есть много встроенных исключений для использования в программе. Но иногда нужно создавать собственные со своими сообщениями для конкретных целей.
Это можно сделать, создав новый класс, который будет наследовать из класса Exception в Python.
В предыдущем примере если ввести что-либо меньше 1, будет вызвано исключение. Многие стандартные исключения имеют собственные исключения, которые вызываются при возникновении проблем в работе их функций.
Недостатки обработки исключений в Python
У использования исключений есть свои побочные эффекты, как, например, то, что программы с блоками try-except работают медленнее, а количество кода возрастает.
Дальше пример, где модуль Python timeit используется для проверки времени исполнения 2 разных инструкций. В stmt1 для обработки ZeroDivisionError используется try-except, а в stmt2 — if . Затем они выполняются 10000 раз с переменной a=0 . Суть в том, чтобы показать разницу во времени исполнения инструкций. Так, stmt1 с обработкой исключений занимает больше времени чем stmt2 , который просто проверяет значение и не делает ничего, если условие не выполнено.
Поэтому стоит ограничить использование обработки исключений в Python и применять его в редких случаях. Например, когда вы не уверены, что будет вводом: целое или число с плавающей точкой, или не уверены, существует ли файл, который нужно открыть.
Выводы!
Как вы могли увидеть, обработка исключений помогает прервать типичный поток программы с помощью специального механизма, который делает код более отказоустойчивым.
Обработка исключений — один из основных факторов, который делает код готовым к развертыванию. Это простая концепция, построенная всего на 4 блоках: try выискивает исключения, а except их обрабатывает.
Очень важно поупражняться в их использовании, чтобы сделать свой код более отказоустойчивым.
Про смартфон — цены, обзоры и реальные отзывы покупателей
На сайте Pro-Smartfon найдёте отзывы и обзоры топовых смартфонов 2017 года. Всё о плюсах и минусах мобильных телефонов. Свежие фотографии, цены и реальные отзывы покупателей о лучших смартфонах
- Главная
- Компьютеры
- Обзоры
- Новости
- Копии
- Разное
- Отзывы
- HTC
- Карта сайта
- Контакты
Eoferror eof when reading a line
Я пытаюсь определить функцию для создания периметра прямоугольника. Вот код:
Я думаю, что я не оставил никаких аргументов открытым или что-то в этом роде.
Запуск таким образом:
Я подозреваю, что IDLE просто передает одну строку в ваш script. Первая input() — это сплошная строка. Обратите внимание, что произойдет, если вы поместите некоторые заявления печати после вызовов input() :
Запуск echo «1 2» | test.py создает
Обратите внимание, что первый оператор печати печатает всю строку ‘1 2’ . Второй вызов input() вызывает ошибку EOFError (ошибка конца файла).
Таким образом, простой канал, такой как тот, который я использовал, позволяет передавать только одну строку. Таким образом, вы можете только один раз вызвать input() . Затем вы должны обработать эту строку, разбить ее на пробелы и преобразовать фрагменты строки в ints самостоятельно. Это то, что
Исключения возникают тогда, когда в программе возникает некоторая исключительная ситуация. Например, к чему приведёт попытка чтения несуществующего файла? Или если файл был случайно удалён, пока программа работала? Такие ситуации обрабатываются при помощи исключений.
Это касается и программ, содержащих недействительные команды. В этом случае Python поднимает руки и сообщает, что обнаружил ошибку.
Ошибки¶
Рассмотрим простой вызов функции print . Что, если мы ошибочно напишем print как Print ? Обратите внимание на заглавную букву. В этом случае Python поднимает синтаксическую ошибку.
Обратите внимание, что была поднята ошибка NameError , а также указано место, где была обнаружена ошибка. Так в данном случае действует обработчик ошибок.
Исключения¶
Попытаемся считать что-либо от пользователя. Нажмите Сtrl-D (или Ctrl+Z в Windows) и посмотрите, что произойдёт.
Python поднимает ошибку с именем EOFError , что означает, что он обнаружил символ конца файла (который вводится при помощи Ctrl-D ) там, где не ожидал.
Обработка исключений¶
Обрабатывать исключения можно при помощи оператора try..except [1]. При этом все обычные команды помещаются внутрь try-блока, а все обработчики исключений – в except-блок.
Пример: (сохраните как try_except.py )
Вывод:
Как это работает:
Помните, что для каждого выражения try должно быть хотя бы одно соответствующее выражение except . Иначе какой смысл был бы в блоке try ?
Если ошибка или исключение не обработано, будет вызван обработчик Python по умолчанию, который останавливает выполнение программы и выводит на экран сообщение об ошибке. Выше мы уже видели это в действии.
Можно также добавить пункт else к соответствующему блоку try..except . Этот пункт будет выполнен тогда, когда исключений не возникает.
В следующем примере мы увидим, как можно получить объект исключения для дальнейшей работы с ним.
Вызов исключения¶
Исключение можно поднять при помощи оператора raise [2], передав ему имя ошибки/исключения, а также объект исключения, который нужно выбросить.
Вызываемая ошибка или исключение должна быть классом, который прямо или непрямо является производным от класса Exception .
Пример: (сохраните как raising.py )
Вывод:
Как это работает:
Здесь мы создаём наш собственный тип исключения. Этот новый тип исключения называется ShortInputException . Он содержит два поля: length , хранящее длину введённого текста, и atleast , указывающее, какую минимальную длину текста ожидала программа.
В пункте except мы указываем класс ошибки ShortInputException , который будет сохранён как[3] переменная ex , содержащая соответствующий объект ошибки/исключения. Это аналогично параметрам и аргументам при вызове функции. Внутри этого пункта except мы используем поля length и atleast объекта исключения для вывода необходимых сообщений пользователю.
Try .. Finally¶
Представим, что в программе происходит чтение файла и необходимо убедиться, что объект файла был корректно закрыт и что не возникло никакого исключения. Этого можно достичь с применением блока finally .
Сохраните как finally.py :
Вывод:
Как это работает:
Здесь мы производим обычные операции чтения из файла, но в данном случае добавляем двухсекундный сон после вывода каждой строки при помощи функции time.sleep , чтобы программа выполнялась медленно (ведь Python очень быстр от природы). Во время выполнения программы нажмите ctrl-c , чтобы прервать/отменить выполнение программы.
Пронаблюдайте, как при этом выдаётся исключение KeyboardInterrupt , и программа выходит. Однако, прежде чем программа выйдет, выполняется пункт finally , и файловый объект будет всегда закрыт.
Оператор with¶
Типичной схемой является запрос некоторого ресурса в блоке try с последующим освобождением этого ресурса в блоке finally . Для того, чтобы сделать это более “чисто”, существует оператор with [4]:
Сохраните как using_with.py :
Как это работает:
Вывод должен быть таким же, как и в предыдущем примере. Разница лишь в том, что здесь мы используем функцию open с оператором with – этим мы оставляем автоматическое закрытие файла под ответственность with open .
За кулисами происходит следующее. Существует некий протокол, используемый оператором with . Он считывает объект, возвращаемый оператором open . Назовём его в данном случае “thefile”.
Перед запуском блока кода, содержащегося в нём, оператор with всегда вызывает функцию thefile.__enter__ , а также всегда вызывает thefile.__exit__ после завершения выполнения этого блока кода.
Так что код, который мы бы написали в блоке finally , будет автоматически обработан методом __exit__ . Это избавляет нас от необходимости повторно в явном виде указывать операторы try..finally .
Более обширное рассмотрение этой темы выходит за рамки настоящей книги, поэтому для более исчерпывающего объяснения см. PEP 343.
Резюме¶
Мы обсудили использование операторов try..except и try..finally . Мы также увидели, как создавать наши собственные типы исключений и как их вызывать.
Далее мы ознакомимся со стандартной библиотекой Python.
Hey. help me please I do calculator. emboss error EOFError: EOF when reading a line here’s the code: while True: print(«Options:») print(«Enter ‘+’ to add two numbers») print(«Enter ‘-‘ to substract two numbers») print(«Enter ‘*’ to multiply two numbers») print(«Enter ‘/’ to div ) I’m not so I do?
1/6/2017 7:50:26 PM
@Ruslan Ovcharenko: We can give multiple inputs by giving one input each in a new line. Perhaps that solves the OP’s issue as well.
sololearn doesn’t support more than one input.
6. Built-in Exceptions¶
Exceptions should be class objects. The exceptions are defined in the module exceptions . This module never needs to be imported explicitly: the exceptions are provided in the built-in namespace as well as the exceptions module.
For class exceptions, in a try statement with an except clause that mentions a particular class, that clause also handles any exception classes derived from that class (but not exception classes from which it is derived). Two exception classes that are not related via subclassing are never equivalent, even if they have the same name.
The built-in exceptions listed below can be generated by the interpreter or built-in functions. Except where mentioned, they have an “associated value” indicating the detailed cause of the error. This may be a string or a tuple containing several items of information (e.g., an error code and a string explaining the code). The associated value is the second argument to the raise statement. If the exception class is derived from the standard root class BaseException , the associated value is present as the exception instance’s args attribute.
User code can raise built-in exceptions. This can be used to test an exception handler or to report an error condition “just like” the situation in which the interpreter raises the same exception; but beware that there is nothing to prevent user code from raising an inappropriate error.
The built-in exception classes can be subclassed to define new exceptions; programmers are encouraged to derive new exceptions from the Exception class or one of its subclasses, and not from BaseException . More information on defining exceptions is available in the Python Tutorial under User-defined Exceptions .
The following exceptions are only used as base classes for other exceptions.
The base class for all built-in exceptions. It is not meant to be directly inherited by user-defined classes (for that, use Exception ). If str() or unicode() is called on an instance of this class, the representation of the argument(s) to the instance are returned, or the empty string when there were no arguments.
New in version 2.5.
The tuple of arguments given to the exception constructor. Some built-in exceptions (like IOError ) expect a certain number of arguments and assign a special meaning to the elements of this tuple, while others are usually called only with a single string giving an error message.
All built-in, non-system-exiting exceptions are derived from this class. All user-defined exceptions should also be derived from this class.
Changed in version 2.5: Changed to inherit from BaseException .
The base class for all built-in exceptions except StopIteration , GeneratorExit , KeyboardInterrupt and SystemExit . StandardError itself is derived from Exception .
The base class for those built-in exceptions that are raised for various arithmetic errors: OverflowError , ZeroDivisionError , FloatingPointError .
Raised when a buffer related operation cannot be performed.
The base class for the exceptions that are raised when a key or index used on a mapping or sequence is invalid: IndexError , KeyError . This can be raised directly by codecs.lookup() .
The base class for exceptions that can occur outside the Python system: IOError , OSError . When exceptions of this type are created with a 2-tuple, the first item is available on the instance’s errno attribute (it is assumed to be an error number), and the second item is available on the strerror attribute (it is usually the associated error message). The tuple itself is also available on the args attribute.
New in version 1.5.2.
When an EnvironmentError exception is instantiated with a 3-tuple, the first two items are available as above, while the third item is available on the filename attribute. However, for backwards compatibility, the args attribute contains only a 2-tuple of the first two constructor arguments.
The filename attribute is None when this exception is created with other than 3 arguments. The errno and strerror attributes are also None when the instance was created with other than 2 or 3 arguments. In this last case, args contains the verbatim constructor arguments as a tuple.
The following exceptions are the exceptions that are actually raised.
Raised when an assert statement fails.
Raised when an attribute reference (see Attribute references ) or assignment fails. (When an object does not support attribute references or attribute assignments at all, TypeError is raised.)
Raised when one of the built-in functions ( input() or raw_input() ) hits an end-of-file condition (EOF) without reading any data. (N.B.: the file.read() and file.readline() methods return an empty string when they hit EOF.)
Raised when a floating point operation fails. This exception is always defined, but can only be raised when Python is configured with the —with-fpectl option, or the WANT_SIGFPE_HANDLER symbol is defined in the pyconfig.h file.
Raised when a generator ’s close() method is called. It directly inherits from BaseException instead of StandardError since it is technically not an error.
New in version 2.5.
Changed in version 2.6: Changed to inherit from BaseException .
Raised when an I/O operation (such as a print statement, the built-in open() function or a method of a file object) fails for an I/O-related reason, e.g., “file not found” or “disk full”.
This class is derived from EnvironmentError . See the discussion above for more information on exception instance attributes.
Changed in version 2.6: Changed socket.error to use this as a base class.
Raised when an import statement fails to find the module definition or when a from . import fails to find a name that is to be imported.
Raised when a sequence subscript is out of range. (Slice indices are silently truncated to fall in the allowed range; if an index is not a plain integer, TypeError is raised.)
Raised when a mapping (dictionary) key is not found in the set of existing keys.
Raised when the user hits the interrupt key (normally Control-C or Delete ). During execution, a check for interrupts is made regularly. Interrupts typed when a built-in function input() or raw_input() is waiting for input also raise this exception. The exception inherits from BaseException so as to not be accidentally caught by code that catches Exception and thus prevent the interpreter from exiting.
Changed in version 2.5: Changed to inherit from BaseException .
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.
Raised when a local or global name is not found. This applies only to unqualified names. The associated value is an error message that includes the name that could not be found.
This exception is derived from RuntimeError . In user defined base classes, abstract methods should raise this exception when they require derived classes to override the method.
New in version 1.5.2.
This exception is derived from EnvironmentError . It is raised when a function returns a system-related error (not for illegal argument types or other incidental errors). The errno attribute is a numeric error code from errno , and the strerror attribute is the corresponding string, as would be printed by the C function perror() . See the module errno , which contains names for the error codes defined by the underlying operating system.
For exceptions that involve a file system path (such as chdir() or unlink() ), the exception instance will contain a third attribute, filename , which is the file name passed to the function.
New in version 1.5.2.
Raised when the result of an arithmetic operation is too large to be represented. This cannot occur for long integers (which would rather raise MemoryError than give up) and for most operations with plain integers, which return a long integer instead. Because of the lack of standardization of floating point exception handling in C, most floating point operations also aren’t checked.
This exception is raised when a weak reference proxy, created by the weakref.proxy() function, is used to access an attribute of the referent after it has been garbage collected. For more information on weak references, see the weakref module.
New in version 2.2: Previously known as the weakref.ReferenceError exception.
Raised when an error is detected that doesn’t fall in any of the other categories. The associated value is a string indicating what precisely went wrong.
Raised by an iterator ’s next() method to signal that there are no further values. This is derived from Exception rather than StandardError , since this is not considered an error in its normal application.
New in version 2.2.
Raised when the parser encounters a syntax error. This may occur in an import statement, in an exec statement, in a call to the built-in function eval() or input() , or when reading the initial script or standard input (also interactively).
Instances of this class have attributes filename , lineno , offset and text for easier access to the details. str() of the exception instance returns only the message.
Base class for syntax errors related to incorrect indentation. This is a subclass of SyntaxError .
Raised when indentation contains an inconsistent use of tabs and spaces. This is a subclass of IndentationError .
Raised when the interpreter finds an internal error, but the situation does not look so serious to cause it to abandon all hope. The associated value is a string indicating what went wrong (in low-level terms).
You should report this to the author or maintainer of your Python interpreter. Be sure to report the version of the Python interpreter ( sys.version ; it is also printed at the start of an interactive Python session), the exact error message (the exception’s associated value) and if possible the source of the program that triggered the error.
This exception is raised by the sys.exit() function. When it is not handled, the Python interpreter exits; no stack traceback is printed. If the associated value is a plain integer, it specifies the system exit status (passed to C’s exit() function); if it is None , the exit status is zero; if it has another type (such as a string), the object’s value is printed and the exit status is one.
Instances have an attribute code which is set to the proposed exit status or error message (defaulting to None ). Also, this exception derives directly from BaseException and not StandardError , since it is not technically an error.
A call to sys.exit() is translated into an exception so that clean-up handlers ( finally clauses of try statements) can be executed, and so that a debugger can execute a script without running the risk of losing control. The os._exit() function can be used if it is absolutely positively necessary to exit immediately (for example, in the child process after a call to os.fork() ).
The exception inherits from BaseException instead of StandardError or Exception so that it is not accidentally caught by code that catches Exception . This allows the exception to properly propagate up and cause the interpreter to exit.
Changed in version 2.5: Changed to inherit from BaseException .
Raised when an operation or function is applied to an object of inappropriate type. The associated value is a string giving details about the type mismatch.
Raised when a reference is made to a local variable in a function or method, but no value has been bound to that variable. This is a subclass of NameError .
New in version 2.0.
Raised when a Unicode-related encoding or decoding error occurs. It is a subclass of ValueError .
UnicodeError has attributes that describe the encoding or decoding error. For example, err.object[err.start:err.end] gives the particular invalid input that the codec failed on.
The name of the encoding that raised the error.
A string describing the specific codec error.
The object the codec was attempting to encode or decode.
The first index of invalid data in object .
The index after the last invalid data in object .
New in version 2.0.
Raised when a Unicode-related error occurs during encoding. It is a subclass of UnicodeError .
New in version 2.3.
Raised when a Unicode-related error occurs during decoding. It is a subclass of UnicodeError .
New in version 2.3.
Raised when a Unicode-related error occurs during translating. It is a subclass of UnicodeError .
New in version 2.3.
Raised when an operation or function receives an argument that has the right type but an inappropriate value, and the situation is not described by a more precise exception such as IndexError .
Only available on VMS. Raised when a VMS-specific error occurs.
Raised when a Windows-specific error occurs or when the error number does not correspond to an errno value. The winerror and strerror values are created from the return values of the GetLastError() and FormatMessage() functions from the Windows Platform API. The errno value maps the winerror value to corresponding errno.h values. This is a subclass of OSError .
New in version 2.0.
Changed in version 2.5: Previous versions put the GetLastError() codes into errno .
Raised when the second argument of a division or modulo operation is zero. The associated value is a string indicating the type of the operands and the operation.
The following exceptions are used as warning categories; see the warnings module for more information.
Base class for warning categories.
Base class for warnings generated by user code.
Base class for warnings about deprecated features.
Base class for warnings about features which will be deprecated in the future.
Base class for warnings about dubious syntax.
Base class for warnings about dubious runtime behavior.
Base class for warnings about constructs that will change semantically in the future.
Base class for warnings about probable mistakes in module imports.
New in version 2.5.
Base class for warnings related to Unicode.
New in version 2.5.
Base class for warnings related to bytes and bytearray.
New in version 2.6.
6.1. Exception hierarchy¶
The class hierarchy for built-in exceptions is: