email.errors: Classes de Exceção e Defeito.

Código-fonte: Lib/email/errors.py

A seguinte classe de exceção é definida no modulo email.errors.

exception email.errors.MessageError

Essa é a classe base para todas as exceções que o pacote email pode levantar. Ela é derivada da classe padrão Exception e não define métodos adicionais.

exception email.errors.MessageParseError

Essa é a classe base para exceções levantadas pela classe Parser. Ela é derivada do MessageError. Essa classe pode ser usada internamente pelo analisador sintático usado pelo headerregistry.

exception email.errors.HeaderParseError

Raised under some error conditions when parsing the RFC 5322 headers of a message, this class is derived from MessageParseError. The set_boundary() method will raise this error if the content type is unknown when the method is called. Header may raise this error for certain base64 decoding errors, and when an attempt is made to create a header that appears to contain an embedded header (that is, there is what is supposed to be a continuation line that has no leading whitespace and looks like a header).

exception email.errors.BoundaryError

Descontinuado e não mais usado.

exception email.errors.MultipartConversionError

Raised when a payload is added to a Message object using add_payload(), but the payload is already a scalar and the message’s Content-Type main type is not either multipart or missing. MultipartConversionError multiply inherits from MessageError and the built-in TypeError.

Since Message.add_payload() is deprecated, this exception is rarely raised in practice. However the exception may also be raised if the attach() method is called on an instance of a class derived from MIMENonMultipart (e.g. MIMEImage).

exception email.errors.HeaderWriteError

Raised when an error occurs when the generator outputs headers.

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

All defect classes are subclassed from email.errors.MessageDefect.

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

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

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

    Novo na versão 3.3.

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

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

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

    Novo na versão 3.3.

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

    Obsoleto desde a versão 3.3: This defect has not been used for several Python versions.

  • MultipartInvariantViolationDefect – A message claimed to be a multipart, but no subparts were found. Note that when a message has this defect, its is_multipart() method may return False even though its content type claims to be multipart.

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

  • InvalidBase64CharactersDefect – When decoding a block of base64 encoded 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 encoded bytes, the number of non-padding base64 characters was invalid (1 more than a multiple of 4). The encoded block was kept as-is.