email.errors: Классы исключений и дефектов

В модуле email.errors определены следующие классы исключений:

exception email.errors.MessageError

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

exception email.errors.MessageParseError

Это базовый класс для исключений, генерируемых классом Parser. Он наследуется от MessageError.

exception email.errors.HeaderParseError

Вызывается при некоторых ошибках при разборе заголовков RFC 2822 сообщения. Этот класс наследуется от MessageParseError. Он может быть вызван методами Parser.parse или Parser.parsestr.

К таким ситуациям относятся: обнаружение заголовка конверта после первого заголовка RFC 2822 сообщения, обнаружение продолжения строки до первого заголовка RFC 2822, или обнаружение строки в заголовках, которая не является ни заголовком, ни продолжением.

exception email.errors.BoundaryError

Вызывается при некоторых ошибках при разборе заголовков RFC 2822 сообщения. Этот класс наследуется от MessageParseError. Он может быть вызван методами Parser.parse или Parser.parsestr.

К таким ситуациям относятся: невозможность найти начальную или конечную границу в сообщении multipart/* при строгом разборе.

exception email.errors.MultipartConversionError

Вызывается, когда содержимое добавляется к объекту Message с помощью add_payload(), но содержимое уже является скаляром, а основной тип содержимого сообщения Content-Type не является multipart или отсутствует. MultipartConversionError многократно наследуется от MessageError и встроенного TypeError.

Поскольку Message.add_payload() устарело, данное исключение редко возникает на практике. Однако исключение также может возникнуть, если метод attach() вызывается на экземпляре класса, унаследованного от MIMENonMultipart (например, MIMEImage).

Вот список дефектов, которые может обнаружить FeedParser при разборе сообщений. Обратите внимание, что дефекты добавляются к сообщению, в котором была обнаружена проблема. Например, если сообщение внутри multipart/alternative имело неправильный заголовок, то у этого вложенного объекта сообщения будет дефект, но у содержащих сообщений дефекта не будет.

Все классы дефектов являются подклассами email.errors.MessageDefect, но этот класс не является исключением!

• NoBoundaryInMultipartDefect – Сообщение утверждало, что является составным, но не имело параметра boundary.
• StartBoundaryNotFoundDefect – Начальная граница, указанная в заголовке Content-Type, никогда не была найдена.
• FirstHeaderLineIsContinuationDefect – Первой строкой заголовка сообщения была строка продолжения.
• MisplacedEnvelopeHeaderDefect – Заголовок «Unix From» был найден в середине блока заголовков.
• MalformedHeaderDefect – Был найден заголовок, в котором отсутствовал двоеточие или он был неправильно сформирован.
• MultipartInvariantViolationDefect – Сообщение утверждало, что является multipart, но вложенных частей не было найдено. Обратите внимание, что когда у сообщения есть этот дефект, его метод is_multipart() может возвращать ложь, даже если его тип содержимого утверждает, что он multipart.