19.1.5.email.errors: Exception and Defect classes¶

Source code:Lib/email/errors.py

The following exception classes are defined in theemail.errors module:

exceptionemail.errors.MessageError¶

This is the base class for all exceptions that theemail package canraise. It is derived from the standardException class and defines noadditional methods.

exceptionemail.errors.MessageParseError¶

This is the base class for exceptions raised by theParser class. It is derived fromMessageError. This class is also used internally by the parser usedbyheaderregistry.

exceptionemail.errors.HeaderParseError¶

Raised under some error conditions when parsing theRFC 5322 headers of amessage, this class is derived fromMessageParseError. Theset_boundary() method will raise thiserror if the content type is unknown when the method is called.Header may raise this error for certain base64decoding errors, and when an attempt is made to create a header that appearsto contain an embedded header (that is, there is what is supposed to be acontinuation line that has no leading whitespace and looks like a header).

exceptionemail.errors.BoundaryError¶

Deprecated and no longer used.

exceptionemail.errors.MultipartConversionError¶

Raised when a payload is added to aMessage objectusingadd_payload(), but the payload is already a scalar and themessage’sContent-Type main type is not eithermultipart or missing.MultipartConversionError multiplyinherits fromMessageError and the built-inTypeError.

SinceMessage.add_payload() is deprecated, this exception is rarelyraised in practice. However the exception may also be raised if theattach()method is called on an instance of a class derived fromMIMENonMultipart (e.g.MIMEImage).

Here is the list of the defects that theFeedParsercan find while parsing messages. Note that the defects are added to the messagewhere the problem was found, so for example, if a message nested inside amultipart/alternative had a malformed header, that nested messageobject would have a defect, but the containing messages would not.

All defect classes are subclassed fromemail.errors.MessageDefect.

• NoBoundaryInMultipartDefect – A message claimed to be a multipart,but had noboundary parameter.

• StartBoundaryNotFoundDefect – The start boundary claimed in theContent-Type header was never found.

• CloseBoundaryNotFoundDefect – A start boundary was found, butno corresponding close boundary was ever found.

  New in version 3.3.

• FirstHeaderLineIsContinuationDefect – The message had a continuationline as its first header line.

• MisplacedEnvelopeHeaderDefect - A “Unix From” header was found in themiddle of a header block.

• MissingHeaderBodySeparatorDefect - A line was found while parsingheaders that had no leading white space but contained no ‘:’. Parsingcontinues assuming that the line represents the first line of the body.

  New in version 3.3.

• MalformedHeaderDefect – A header was found that was missing a colon,or was otherwise malformed.

  Deprecated since version 3.3:This defect has not been used for several Python versions.

• MultipartInvariantViolationDefect – A message claimed to be amultipart, but no subparts were found. Note that when a messagehas this defect, itsis_multipart() method mayreturn false even though its content type claims to bemultipart.

• InvalidBase64PaddingDefect – When decoding a block of base64encoded bytes, the padding was not correct. Enough padding is added toperform the decode, but the resulting decoded bytes may be invalid.

• InvalidBase64CharactersDefect – When decoding a block of base64encoded bytes, characters outside the base64 alphabet were encountered.The characters are ignored, but the resulting decoded bytes may be invalid.

• InvalidBase64LengthDefect – When decoding a block of base64 encodedbytes, the number of non-padding base64 characters was invalid (1 more thana multiple of 4). The encoded block was kept as-is.